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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 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 10:31:23 -0400

>> > Then I guess you or Ihor (or both) should try removing that line and
>> > run with that for a while.
>> FWIW, I've been running without those two lines ever since I put this FIXME.
> I'd be happier with the alternative I proposed, which you cite below.

I assume you assumed that my lack of problems would make me think
removing those two lines is safe :-)

I'm fully aware that when it comes to redisplay, one or two testers are
definitely far from sufficient, don't worry.

>> > Alternatively, maybe in the case of ALL non-nil the code should set
>> > the prevent_redisplay_optimizations_p flag of all the buffers that are
>> > displayed in some window, since some redisplay optimizations are not
>> > eligible when the mode-line is about to be updated.
>> 
>> Any reason why the corresponding optimizations don't consult the
>> `update_mode_lines` var (or the `update_mode_line` buffer flag), or
>> maybe have redisplay start by propagating the `update_mode_line` buffer
>> flag to `prevent_redisplay_optimizations_p`?
>
> Once again, prevent_redisplay_optimizations_p is NOT (just) about
> updating mode lines, it affects more optimizations.  There's also

I know.  I didn't mean "consult `update_mode_lines` instead of
`prevent_redisplay_optimizations_p`" but "consult `update_mode_lines` in
addition to `prevent_redisplay_optimizations_p`".

> It would be nice to analyze all those flags, make them more selective,
> and understand/document better what optimizations and optional
> processing are affected by each one of them.  It is a large and
> somewhat ungrateful job, so if someone wants to do it by
> systematically examining the situations where we set each one of those
> flags and their effects on redisplay, I can offer my best help (though
> I cannot afford doing this job myself).

I can't see it happening ever in such a systematic way.
A more pragmatic approach is the one you propose afterwards: based on
our vague understanding of how things work, make a few simplifications,
expose them to our users and then see what bug reports we get in return.

I suspect a single boolean variable (which we could call
`internal--use-old-slow-redisplay`) to control those simplifications
would be enough.

We could set it to nil on `master` and to t in the release branch.


        Stefan

Previous Next

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