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

Previous Next

Package: emacs;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Sun, 8 May 2022 11:54:02 UTC

Severity: normal

Found in version 29.0.50

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

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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.




This bug report was last modified 3 years and 16 days ago.

Previous Next


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