GNU bug report logs - #55312
29.0.50; Cannot set vscroll when mini-window is resized

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Po Lu <luangruo <at> yahoo.com>
Subject: bug#55312: closed (Re: bug#55312: 29.0.50; Cannot set vscroll
 when mini-window is resized)
Date: Mon, 09 May 2022 01:40:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#55312: 29.0.50; Cannot set vscroll when mini-window is resized

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 55312 <at> debbugs.gnu.org.

-- 
55312: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55312
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55312-done <at> debbugs.gnu.org
Subject: Re: bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
Date: Mon, 09 May 2022 09:38:46 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks.  I think I'd prefer the latter, and will begin working on it.

Now done, so I'm closing this bug report.

[Message part 3 (message/rfc822, inline)]

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Cannot set vscroll when mini-window is resized
Date: Sun, 08 May 2022 19:53:10 +0800

It seems that this code in redisplay_window always clears out the
vscroll when the mini-window is taller than a single line of text:

  /* If someone specified a new starting point but did not insist,
     check whether it can be used.  */
  if ((w->optional_new_start || window_frozen_p (w))
      && CHARPOS (startp) >= BEGV
      && CHARPOS (startp) <= ZV)
    {
      ptrdiff_t it_charpos;

      w->optional_new_start = false;
      start_display (&it, w, startp);
      move_it_to (&it, PT, 0, it.last_visible_y, -1,
		  MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
      /* Record IT's position now, since line_bottom_y might change
	 that.  */
      it_charpos = IT_CHARPOS (it);
      /* Make sure we set the force_start flag only if the cursor row
	 will be fully visible.  Otherwise, the code under force_start
	 label below will try to move point back into view, which is
	 not what the code which sets optional_new_start wants.  */
      if ((it.current_y == 0 || line_bottom_y (&it) < it.last_visible_y)
	  && !w->force_start)
	{
	  if (it_charpos == PT)
	    w->force_start = true;
	  /* IT may overshoot PT if text at PT is invisible.  */
	  else if (it_charpos > PT && CHARPOS (startp) <= PT)
	    w->force_start = true;

This can easily be reproduced by typing "M-x C-q C-j" and trying to use
`pixel-scroll-precision' with the mouse pointer on top of a window that
is not the `minibuf-scroll-window': the vscroll will not take effect,
since force_start will be set to true, and that resets the vscroll.

I think this "frozen" behavior is required to ensure that the start of
windows do not aimlessly move when the mini-window is being resized, but
it interferes with features that need to set the vscroll.

Any ideas?

Thanks in advance.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.