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

[Stefan Monnier]

> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.

It's not that simple: the reliable way to do redisplay is to recompute
the whole glyph matrix anew for all windows every time any change occurs.
But that's unrealistic  Instead, we decouple the redisplay from the
buffer modifications.  In addition we try to keep track of which parts
may need to be redisplayed.  For that we use various auxiliary variables
which the code performing modifications can set to tell the redisplay
about which parts may need to be redisplayed.

Such variables include the `redisplay` and the `update_mode_line` bits,
buffer vars that keep track of a buffer-interval outside of which
there has not been any buffer changes, ...

`prevent_redisplay_optimizations_p` is just another of those vars.
The problem with that var is not its existence but the fact that by now
noone knows what it means, so we can't touch that code, basically :-(

> 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.

I suspect the `prevent_redisplay_optimizations_p` is/was not meant to make
sure the modeline is updated, but to make sure some other part of the
window is/was also updated, but the code that decides whether to redraw
that other part never looked at `update_mode_line`.

E.g. maybe some code caused the mode-line or header-line to
appear/disappear and thus called `force-mode-line-update` for that
purpose, but the redisplay failed to notice that it needed to redraw
parts of the buffer text in response o that change, so the "quick fix"
was to set `prevent_redisplay_optimizations_p`?
[ This is a completely hypothetical scenario, I have no idea how this
  code came about.  ]

> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p?

I don't know if it's still needed, or (if it is) whether it's the best
way to get the result nowadays, but I know why it's done: it's simply
because Fforce_mode_line_update used not to exist and instead the
standard way to force a mode-line update was to call
`set-buffer-modified-p` (yeah, I know it's weird, but that was simply
the cheapest operation exposed to ELisp that happened to set the needed
flags for the redisplay).  `force-mode-line-update` was introduced as
a cleaner API (but still implemented by calling
`set-buffer-modified-p`), so when I "straightened things out" by making
`force-mode-line-update` set the redisplay flags directly, I made
`set-buffer-modified-p` call `Fforce_mode_line_update` to be sure that
any old code out there calling `set-buffer-modified-p` to force a mode
line update would keep working as well as before.

> Wouldn't calling bset_redisplay be better?

Maybe (depends whether the redisplay code on its own checks stores the
old modified-p value to detect when it has changed), tho I doubt it
matters very much.


        Stefan