GNU bug report logs - #70038
29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 70038 <at> debbugs.gnu.org
Subject: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
Date: Sun, 28 Apr 2024 10:51:38 +0200

> Where would you like to put the comment, and what should that comment
> say?

There are three issues I don't understand well in this context.  The
first one concerns the preserve_vscroll_p flag we currently check as:

      if (!w->preserve_vscroll_p && !window_frozen_p (w))
	w->vscroll = 0;

Here, in all scenarios I tried, I observed that w->preserve_vscroll_p
implies window_frozen_p (w) which IIUC means that the preserve_vscroll_p
flag is not needed and we could simplify the above to

      if (!window_frozen_p (w))
	w->vscroll = 0;

What am I missing here?


The second issue is why we freeze window starts at all.  Conceptually,
when window starts are frozen, redisplay should not change the start
position of _any_ window whenever we enlarge the mini window.  But
window_frozen_p returns false for the selected and minibuffer scroll
windows.  Hence, freezing does not set force_start for these windows.

While this discrimination seems unwanted (in particular when resizing
the echo area), it apparently doesn't matter in any of the scenarios I
tried here - the start positions of all windows remain unchanged in
precisely the same way regardless of whether they are selected or not.
So IIUC we could do away with freezing as well.

The only new issue now is that if window starts are no more frozen, we'd
always (or never) reset w->vscroll in force_start.  But, as mentioned
before, resetting w->vscroll only in non-selected, non-minibuffer
windows doesn't seem very optimal anyway.  And resetting w->vscroll is
IMHO problematic in another way: After having set vscroll for a window,
why does moving point _within_ that window reset it?  Wouldn't it be
more logical to reset vscroll iff a new start position for the window
has to be found - either explicitly due to a scroll command or
implicitly to move point back into view (including the case where
vscroll itself caused point to move off-screen)?

I suppose that I'm missing some optimization issue here but fail to see
what it is.


The third issue is that of the optional_new_start flag: All 'recenter'
effectively does is to calculate a new start position of a window and
ask redisplay to apply it.  Now why does 'recenter' in particular set
that flag and why does none of the other functions that set a window's
start position like 'scroll-up' or 'scroll-down' set it?  IIUC nothing
should prevent us from doing away with that flag too.  Unless, again I'm
missing something important here too.


Maybe also some of the force vs ignore window starts dichotomy stems
from earlier versions of redisplay where, as for example, in the

  if ((w->optional_new_start || window_frozen_p (w))

section, we did not care about scroll margins but somewhere below we now
check them anyway.  Or pathological cases we didn't handle earlier like
that of a cursor not becoming fully visible when the line it is on is
too high to fit into its window's body.


Note that I'm not asking to revise code that works sufficiently well
now.  But clarifying the issues I tried to sketch above in the comment
preceding redisplay_window could be useful to better understand bugs
like the one that triggered this thread.

Thanks, martin

Previous Next

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