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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 64596 <at> debbugs.gnu.org
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Sun, 16 Jul 2023 14:53:03 -0400

>> Hmm... I'm not sure why you're saying
>> 
>>     frame's redisplay flag is what causes us to consider a frame in the
>>     first place.
>
> Because fset_redisplay does this:
>
>   void
>   fset_redisplay (struct frame *f)
>   {
>     redisplay_other_windows ();
>     f->redisplay = true;
>   }
>
> and redisplay_other_windows sets windows_or_buffers_changed, which
> then causes consider_all_windows_p to be true upon the next redisplay
> cycle:
>
>   consider_all_windows_p = (update_mode_lines
> 			    || windows_or_buffers_changed);

Yes, most calls to `[fbw]set_redisplay` will call
`redisplay_other_windows` and once that function has been called, all
the frames will be "considered", but that happens regardless of the
`redisplay` bit of any particular frame.

The `redisplay` bit is consulted later, once we loop over all the
windows in all those frames, where we decide which of those windows are
updated depending on the `redisplay` bits of the window, the window's
buffer, and the window's frame.

Are you maybe confused by the name of the `FRAME_REDISPLAY_P` macro,
which does *not* pay attention to the `redisplay` bit?

> IOW, this is not just a matter of exposing a small number of functions
> to Lisp, IMO.

I'm sorry if I made you think I suggested it would be a simple matter.


        Stefan

Previous Next

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