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

[Stefan Monnier]

> 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
>   . update_mode_line flag of a window
>   . update_mode_lines variable
>   . windows_or_buffers_changed variable

I can explain what these are supposed to represent (IOW, if there's
a bug linked to them, I should be able to tell you whether the blame
goes to the redisplay code (which "reads" these vars) or in the
non-redisplay code (which sets these vars)).

If you read their docs and have questions, I'd love to hear them so
I can improve their doc.

>   . clip_changed flag of a buffer
    . beg_unchanged of a buffer_text
    . end_unchanged of a buffer_text

I think their intended meaning is fairly clear.  I haven't really
played with the corresponding part of the code, so I don't know if the
code really matches my expectations, but I have the impression that
there shouldn't be too many surprises.

>   . cursor_type_changed flag of a frame
>   . face_change flag of a frame

I can see what these are supposed to mean as well, but I'm less sure
that that intended meaning really matches the code (e.g., I wouldn't be
surprised to discover that one of them is also (ab)used for something
else).

>   . prevent_redisplay_optimizations_p flag of a buffer
>   . must_be_updated_p flag of a window

No idea what these mean.
The name `must_be_updated_p` makes it sound to me like it's redundant
with the `redisplay` flag above.

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

They were added exclusively to refine:

    . update_mode_lines variable
    . windows_or_buffers_changed variable

since these have a global meaning whereas in most cases only a small
number of the windows should be affected.

[ IOW, the refinement targeted use cases where there are many windows.
  I often have a hundred windows or more :-)  ]

> performance problem.  Because otherwise making changes in code that we
> don't sufficiently understand can only cause bugs,

It can introduce bugs, but in my experience when dealing with code
I don't understand, it's by breaking the code that you learn how it
works, so saying "can only cause bugs" doesn't make sense.  The change
can bring more clarity to the code, which is beneficial in the long
term, and if it introduces bugs then presumably some users will see
them, report them, and that will bring us better understanding of
the code.

That's eactly what happened when I introduced the 3 `redisplay` bits
above: it did introduce a few bugs, but overall it made the code
more clear.  My experience has been very positive there, and I hope you
wouldn't veto a similar change in the future.

> and guess who gets to work on fixing them.

AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
it should.  And it wasn't terribly hard (largely because I indeed knew
(because I had decided it myself) what meant what and hence where
a problem should be fixed).


        Stefan