bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Sun, 16 Jul 2023 10:26:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>>> I agree about must_be_updated_p. I had exactly same though that it is
>>> redundant with redisplay flag when reading the code.
>> Look closer, please.  The name of the flag might suggest what you say,
>> but its usage suggests otherwise.
> Do I understand correctly that prevent_display_optimizations_p in
> buffer, must_be_updated_p in window, and garbaged in frames all serve
> the same purpose of forcing the redisplay?

My understanding of the redisplay code is that it's split into 3 part:

1- decide which windows may need to be updated.
2- update the glyph matrix of a window.
3- update the glass by comparing the old glyph matrix and the new one.

[ The point between 1 and 2 is made visible to ELisp via
  `pre-redisplay-function`.  ]

The `redisplay` bits belong to step (1).
The `prevent_display_optimizations_p` OTOH belong to step 2, AFAIU.

BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
redisplay could be moved to ELisp.  This would allow for example
`follow-mode` to pick a more appropriate order in which to process the
windows at step 2.

> Then, why not use uniform naming scheme and have the buffer/window/frame
> flags names as maybe_redisplay and must_redisplay instead of different
> flag name for different object type?

For that someone first needs to have a clear idea of what these things
do and how they relate to each other :-)


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]