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

Previous Next

Full log

Message #179 received at 64596 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64596 <at> debbugs.gnu.org
Subject: Re: 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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.