Package: emacs;
Reported by: Ihor Radchenko <yantar92 <at> posteo.net>
Date: Thu, 13 Jul 2023 13:01:02 UTC
Severity: normal
Found in version 30.0.50
View this message in rfc822 format
From: Eli Zaretskii <eliz <at> gnu.org> To: Ihor Radchenko <yantar92 <at> posteo.net> Cc: monnier <at> iro.umontreal.ca, 64596 <at> debbugs.gnu.org Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) Date: Fri, 14 Jul 2023 15:25:24 +0300
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 11:53:02 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > No, it's more subtle. In a nutshell, it is meant to prevent redisplay
> > from applying certain optimizations (search xdisp.c for the uses of
> > this flag). These optimizations are based on various assumptions,
> > such as that the current glyph matrix of the window is up-to-date.
> > Setting the prevent_redisplay_optimizations_p flag tells the display
> > engine that those assumptions are (or might be) false.
>
> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.
I think you should avoid making such comments until you have a better
understanding of the redisplay logic, or else I will stop taking your
posts in this matter seriously.
> Currently, redisplay_internal has a number of conditions used to
> determine if one or another optimization is safe to use + assertion that
> !prevent_redisplay_optimizations_p.
>
> When some code outside xdisp.c sets this flag, it is nothing but a
> statement: "I was lazy enough to update xdisp.c properly, so I just
> force bypassing optimizations".
No. The optimization in question, which is disabled when
prevent_redisplay_optimizations_p flag is set for the current buffer,
is described in the comment before the condition:
/* Optimize the case that only the line containing the cursor in the
selected window has changed.
The prevent_redisplay_optimizations_p flag says, among other things,
that we are not in that case, and it is tested early enough in order
to prevent us from examining additional conditions which are just
waste of CPU cycles (and some of them are relatively expensive).
> > Updating the mode line usually requires more thorough redisplay,
> > especially when the only reason for that is that some Lisp called
> > force-mode-line-update -- without setting that flag, the display
> > engine could easily decide that the window doesn't need to be redrawn.
>
> I have explored xdisp a bit and AFAIU, once we are in redisplay_window,
> mode line will be updated as long as update_mode_line is set (at least
> to UPDATE_SOME), except when current window is MINI_WINDOW_P (this code
> branch is not prevented by prevent_redisplay_optimizations_p though) or
> when we give up redisplaying.
>
> Calling redisplay_window may be prevented via needs_no_redisplay, unless
> we have buffer->text->redisplay, which is set in bset_update_mode_line.
> [ setting buffer->text->redisplay is rather awkward way to single mode
> line update though ]
>
> redisplay_window may also be postponed for frames that are not visible
> or that are obscured, but it appears to be by design and not influenced
> by prevent_redisplay_optimizations_p anyway 😕
>
> So, I see not why calling bset_update_mode_line is not sufficient to
> force mode line update in all windows associated with a single buffer.
The mode line displays quite a lot of information. It could also
display information we don't know about (on the level of the redisplay
code), because mode-line-format supports :eval, which can execute any
Lisp. Therefore, there could be changes to the buffer that affect the
mode line indirectly.
One problem of this kind which we had relatively recently is when the
changes in mode-line-format or some of its :eval forms yields a mode
line that is significantly taller or smaller than the previously
displayed one. Such changes in the mode-line height generally affect
the window(s) as well, not just the mode line itself.
Moreover, you will see in the wild that force-mode-line-update is used
not just to update the mode line, but also to force a more thorough
redisplay of one or more windows.
Thus, this is not as simple a problem as you seem to think, and we
need deeper analysis and more significant changes than simply deleting
the code that you didn't understand and think is redundant. Please
keep in mind that people who wrote that code (and I don't mean myself)
were not stupid at all, and generally knew what they were doing!
> >> If my understanding is correct,
> >> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> >> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
> >
> > The purpose of force-mode-line-update is to do what its name says,
> > regardless of whether the buffer was modified or not, and how it was
> > modified. The idea is that Lisp programs which change something that
> > they know must affect the mode line call this function to make sure
> > the mode line is redrawn with up-to-date information. By contrast,
> > buffer modifications could be such that don't affect redisplay at all,
> > or allow redisplay to use some shortcuts and redraw only a very small
> > portion of the window.
>
> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?
You have read the large comment there which attempts to answer this
question, didn't you?
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.