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>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#55312: closed (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 message dated Mon, 09 May 2022 09:38:46 +0800
with message-id <87y1zb32op.fsf <at> yahoo.com>
and subject line Re: bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
has caused the debbugs.gnu.org bug report #55312,
regarding 29.0.50; Cannot set vscroll when mini-window is resized
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: 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.

[Message part 3 (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.

Previous Next

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