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

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org
> Date: Fri, 14 Jul 2023 22:06:38 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 64596@debbugs.gnu.org
> > Date: Fri, 14 Jul 2023 17:46:09 +0000
> > 
> > Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > 
> > > What we need in order to investigate is a somewhat reproducible test
> > > case and for that we need the bug to be exposed to as many users as
> > > possible to increase the chance that one of them bumps into
> > > a good recipe.
> > >
> > > The variable is not used to investigate, but to make it ethical to
> > > expose users to those potential bugs because they can set the var to
> > > recover the old behavior as soon as they're tired of playing the
> > > guinea pig.
> > 
> > +1.
> 
>  -1000

Let me explain once again my position on this.

We currently have quite a few flags that are used by various Emacs
commands to give redisplay hints about what should be done:

  . redisplay flag of a buffer
  . redisplay flag of a window
  . redisplay flag of a frame
  . prevent_redisplay_optimizations_p flag of a buffer
  . clip_changed flag of a buffer
  . update_mode_line flag of a window
  . must_be_updated_p flag of a window
  . cursor_type_changed flag of a frame
  . face_change flag of a frame
  . update_mode_lines variable
  . windows_or_buffers_changed variable

(There are a few more, but these are the bulk.)  The 3 redisplay flags
at the beginning of this list did not exist before Emacs 24, they were
added in the hope to make the flags more selective and
self-explanatory.  But just knowing, for example, that a buffer's text
was changed says almost nothing about which optimizations can and
cannot be used, whether or not the mode line needs to be updated, nor
even if the window(s) showing the buffer need to be redrawn (since the
change could be in a portion of the buffer that is not visible in any
of the windows).

Anyway, we now have this dozen of flags and variables, and one of them
is prevent_redisplay_optimizations_p.  It makes absolutely no sense to
me to try to "solve" the "problem" of this single flag in the single
case that started this thread.  Even if this flag should not be set in
the particular place with a FIXME -- which was not convincingly
demonstrated here -- so what? what harm can that possibly make in this
specific case?  None.  What we have now might look untidy at best, but
it does work, and works well.  It took an effort to get here, but the
current situation has been stable for several years: I don't remember
any significant redisplay problems reported for the last several
years.

What we do need is to make some better order out of these flags,
understand better what does each one of them tell the display engine,
and perhaps make some of them more selective.  And we need to document
these understandings.

So this is the deal: if someone wants to try to do this job, or even
some part of it, you will have my full support, my attention, and any
form of help I can practically provide.  But I will not agree to
random poking at this or that particular flag, unless there's
convincing evidence that it causes a display bug or a significant
performance problem.  Because otherwise making changes in code that we
don't sufficiently understand can only cause bugs, and guess who gets
to work on fixing them.