bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org
> Date: Fri, 14 Jul 2023 13:48:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> Your answer indicates that I missed something important after reading
> the top comment in xdisp.c, redisplay_internal, redisplay_window, and
> skimmed through a couple of other functions. But I still cannot figure
> out what.

Keep studying the code, is all I can suggest.  There's much more there
than meets the eye, IME.

> Note that I did not mean that previous committers had bad intentions. I
> just think that the idea of having "disable all optimizations" flag is
> causing the code quality that could be otherwise somewhat better (at
> least, more explicit about why redisplay should take long path).

I agree that the underlying logic is somewhat subtle, and sometimes
even mysterious, and I suggested a way to make this logic more
explicit and better documented.  But removing parts of display code
because we don't always understand it is a bad idea, IME, and usually
leads to bugs.  So it is a non-starter, as far as I'm concerned.

> I think that replacing all the instances of setting this flag to more
> explicit alternatives would improve the display performance and also
> readability.

It's possible.  But to consider such suggestions, I'd need to see a
detailed proposal backed up by serious analysis.  In any case, whether
it will make performance better is not yet clear; the original
motivation for this was not a performance issue at all.

> >   /* 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).
> 
> Sure, but it is a very generic way to say this. It provides no detailed
> reason what exactly changed in the buffer/window/frame that makes us
> bypass this optimization.

What detailed reasons would you like to see?

> Is it not always possible to use the other, more specific, existing
> flags for redisplay to indicate that something important has been changed?

Which other flags?  And why do you think they are more specific?  At
least some of them are actually _less_ specific.

> >> 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.
> 
> But isn't :eval processed by display_mode_lines? Once we take care to call
> bset_update_mode_line, display_mode_lines is guaranteed to be executed,
> AFAIU.

Executed, but with what data?  redisplay_window is a large function,
and employs quite a few of shortcuts.  If one of those shortcuts is
taken when it shouldn't be, the data shown on the mode line might be
inaccurate, because some of the variables affecting it were not
updated.

But let me turn the table and ask you: suppose that the
prevent_redisplay_optimizations_p flag is not needed for updating the
mode line per se -- what damage could it possibly do to redisplaying
the mode line? why are you so eager to remove that setting from
force-mode-line-update?

> > 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.
> 
> Sure, and redisplay_window accounts for this when calling display_mode_lines:
> 
>       display_mode_lines (w);
>       unbind_to (count1, Qnil);
> 
>       /* If mode line height has changed, arrange for a thorough
>        immediate redisplay using the correct mode line height.  */
>       if (window_wants_mode_line (w)
>         && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
>       {
>         f->fonts_changed = true;
>         w->mode_line_height = -1;
>         MATRIX_MODE_LINE_ROW (w->current_matrix)->height
>           = DESIRED_MODE_LINE_HEIGHT (w);
>       }

And if you've read the relevant bug reports, this doesn't always work.

But this is just an example, so even if you consider it to be solved,
it tells us that there can be other issues like that.  We are trying,
slowly, to go from general flags to more specific ones, but we are not
there yet, and removing code in this situation will just produce more
buggy redisplay.  I cannot agree to that.

> > 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.
> 
> Why not `force-window-update'? 

Why does it matter? they both do almost the same (when the argument to
force-window-update is a window).

> And I now looked deeper into the code, and see no obvious downsides of
> removing current_buffer->prevent_redisplay_optimizations_p = true; from
> force-mode-line-update specifically.
> `set-buffer-modified-p' may need to be re-considered though as it is the
> original place where setting prevent_redisplay_optimizations_p was done
> (for different reasons).

Again, removing this is a non-starter, except if you want to do it
locally.  If we want to make any progress in this area in general, we
should take one of the two approaches I described in my previous
message.  Anything else is simply irresponsible, and won't happen on
my watch, sorry.