all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
       [not found] <877d6w44wp.fsf.ref@yahoo.com>
@ 2022-05-08 11:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-05-08 13:40   ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-08 11:53 UTC (permalink / raw)
  To: 55312

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
  2022-05-08 11:53 ` bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-05-08 13:40   ` Eli Zaretskii
  2022-05-09  0:29     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-05-08 13:40 UTC (permalink / raw)
  To: Po Lu; +Cc: 55312

> Date: Sun, 08 May 2022 19:53:10 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@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:

Not when it's taller, but when it has been resized.

> 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?

If you want to allow vscroll in these cases, you'd need to either add
code which ensures the window-start of "frozen" windows is not moved
by means other than the force_start flag, or modify the code where we
handle the force_start flag so that it doesn't reset vscroll when
pixel-scroll uses it, as opposed to when vscroll is used by "normal"
scrolling commands for the purposes of scrolling tall screen lines.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
  2022-05-08 13:40   ` Eli Zaretskii
@ 2022-05-09  0:29     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-05-09  1:38       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-09  0:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 55312

Eli Zaretskii <eliz@gnu.org> writes:

> If you want to allow vscroll in these cases, you'd need to either add
> code which ensures the window-start of "frozen" windows is not moved
> by means other than the force_start flag, or modify the code where we
> handle the force_start flag so that it doesn't reset vscroll when
> pixel-scroll uses it, as opposed to when vscroll is used by "normal"
> scrolling commands for the purposes of scrolling tall screen lines.

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
  2022-05-09  0:29     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-05-09  1:38       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-05-09 13:48         ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-09  1:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 55312-done

Po Lu <luangruo@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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
  2022-05-09  1:38       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-05-09 13:48         ` Eli Zaretskii
  2022-05-10  0:43           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-05-09 13:48 UTC (permalink / raw)
  To: Po Lu; +Cc: 55312

> From: Po Lu <luangruo@yahoo.com>
> Cc: 55312-done@debbugs.gnu.org
> Date: Mon, 09 May 2022 09:38:46 +0800
> 
> Po Lu <luangruo@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.

Hmm... shouldn't we reset the new flag not just when w->force_start is
non-zero?  Otherwise, the flag could survive more than a single
redisplay cycle, and affect situations that the caller of
set-window-vscroll didn't intend, no?

How about resetting the flag in mark_window_display_accurate_1 as
well?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized
  2022-05-09 13:48         ` Eli Zaretskii
@ 2022-05-10  0:43           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 6+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-05-10  0:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 55312

Eli Zaretskii <eliz@gnu.org> writes:

> How about resetting the flag in mark_window_display_accurate_1 as
> well?

Sure, that's fine by me too.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-05-10  0:43 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <877d6w44wp.fsf.ref@yahoo.com>
2022-05-08 11:53 ` bug#55312: 29.0.50; Cannot set vscroll when mini-window is resized Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-08 13:40   ` Eli Zaretskii
2022-05-09  0:29     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-09  1:38       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-09 13:48         ` Eli Zaretskii
2022-05-10  0:43           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.