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
Message #77 received at 70038 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 15 Apr 2024 11:23:18 +0200
> Cc: luangruo <at> yahoo.com, 70038 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
>
> > Did I succeed explaining the issue?
>
> Not yet.
You asked what harm could unnecessarily frozen window-start do, and I
explained that: it causes us to run more expensive code. Now you are
asking a different question: why do we freeze window-start points at
all? Let me try to answer that as well.
> When we freeze window starts in the case at hand we do that to
> approximate the behavior of a 'save-window-excursion'. But doesn't
> Emacs always try to preserve window start positions regardless of
> whether it enlarges or shrinks a window?
It does, but what it will do if the current window-start doesn't show
point depends on whether or not we take the "force_start" path. See
below.
> So what, if possibly, could
> motivate Emacs to "willfully" change a start position?
For example, if point is not visible in the window, or is on a screen
line that is only partially visible, or is inside the scroll-margin.
> It's obvious that
> 'recenter' asks for it and sets optional_new_start. It's already not
> clear to me why 'delete-other-windows' should want it. So why treating
> frozen starts like asking for new start positions is still a mystery to
> me ...
See above. Basically, anything that changes the window geometry can
potentially cause us to want to move the window-start point.
> I suppose that freezing should handle one situation only: Emacs enlarges
> the mini window, shrinks another window for that purpose and - for a
> reason that is still unclear to me as mentioned above - would like to
> change that window's start position. To avoid that - Emacs will still
> have to change the start position to avoid that point goes off-screen -
> we set that flag. Now it seems obvious that shrinking the mini window
> and thus enlarging another window cannot harm in this regard since
> otherwise we couldn't have reset the flag when shrinking a mini window
> as we did earlier. Is it about making the cursor line fully visible?
Yes. More generally, if the force_start flag is NOT set, and using
the current window-start doesn't produce point in a fully-visible
screen line and out of the scroll margins, then Emacs will try to find
a different window-start point (even recentering the window around
point if nothing else works). By contrast, if the force_start flag
_is_ set, Emacs will instead move point to bring it inside the window,
without changing window-start. When the window-start is frozen, we
quickly determine whether using the current window-start will leave
point inside the window, and if so, we set the force_start flag
ourselves, to prevent redisplay_window from changing window-start.
I hope this is now more clear.
> > Is that in addition to what I suggested to do in shrink_mini_window?
>
> It should replace it.
Hmm... I don't like leaving shrink_mini_window without the reset.
> > Also, shouldn't we do this instead:
> >
> >> - FRAME_WINDOWS_FROZEN (f) = true;
> >> + FRAME_WINDOWS_FROZEN (f) = (old_height + delta > min_height) ? true : false;
> >
> > IOW, shouldn't we unfreeze only when resizing to the default one-line
> > height?
>
> Since every enlarging of the mini window freezes starts again, this
> shouldn't be necessary. But to make sure that we cover all possible
> scenarios we could use the below.
Thanks, I like this much better. Now installed on master.
This bug report was last modified 1 year and 53 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.