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: Tue, 18 Jul 2023 09:52:28 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> May someone then detail these steps in the top commentary in xdisp.c +
> >> highlight that redisplay term is generally used when deciding if we need
> >> to update.
> >
> > It's already in the large commentary at the beginning of xdisp.c
> > (search for "update_window" to find the description of "update").  It
> > just "drowns" in the sea of the information there
> 
> I saw this. But "update" is not used consistently across that
> commentary.

Tough.  "Update" is too general a word to limit is use.  Sorry.

> If we read at the very beginning:
> 
>     /* New redisplay written by Gerd Moellmann <gerd@gnu.org>.
>     
>        Redisplay.
>     
>        Emacs separates the task of updating the display from code
>        modifying global state, e.g. buffer text. ...
>     
>        Updating the display is triggered by the Lisp interpreter when it
>        decides it's time to do it....
> 
> Which immediately creates an impression that "redisplay" and "update"
> are referring to the same thing.

There's no practical way to avoid all the possible misinterpretations
of this large and complex text, especially when it is read for the
first time.

> It would be nice the highlight the distinction rightaway there.

If someone wants to work on making this commentary more clear, please
do.  But in general, I think we are splitting hair here.  This
commentary is intended as an introduction to reading the code and some
kind of general guidelines.  It doesn't pretend to be a detailed and
comprehensive documentation of everything that happens in the display
engine.  Rest assured that there are important aspects and algorithms
of the display engine that are completely absent from this commentary.

>        You will find a lot of redisplay optimizations when you start
>        looking at the innards of redisplay.  The overall goal of all these
>        optimizations is to make redisplay fast because it is done
>        frequently.  Some of these optimizations are implemented by the
>        following functions:
> 
> focuses on optimizations related to window, but says nothing about
> checking frames. 

Because nothing interesting happens on frames that can be described as
"redisplay optimizations".  The only situation where some important
optimizations do happen there is on TTY frames, and that _is_ covered:
see the section headed "Frame matrices".

>                   It talks not about buffers displayed in multiple
> windows either.

Again, no redisplay optimizations consider multiple windows; they all
work on a single window.  And the text doesn't describe many more
other things.  Like I said: this is intended to be an introduction and
a "guide for the perplexed", not a full and detailed documentation --
that would be a much larger job and a much longer text.

Informative additions to this commentary are welcome, of course.

> The rest of the commentary is diving deep into the "update" part.
> Redisplay and its optimizations are not described in sufficient detail.

This is a misunderstanding: where that part talks about "updating the
display", it actually means updating the window's glyph matrix.  The
only "optimization" in the "update" part is that we write to the glass
only the portions where the current and the desired glyph matrices
differ, and cannot be made identical by moving pixels on the screen
(as opposed to actually displaying new pixels).