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 14:53:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

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






reply via email to

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