Subject: bug#55312: closed (Re: bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 09 May 2022 01:40:02 +0000

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 [email-masked].

-- 
55312: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55312
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
From: Po Lu <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked]
Date: Mon, 09 May 2022 09:38:46 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

Po Lu <[email-masked]> writes:

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

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

Subject: 29.0.50; Cannot set vscroll when mini-window is resized
From: Po Lu <[email-masked]>
To: [email-masked]
Date: Sun, 08 May 2022 19:53:10 +0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.