GNU bug report logs -
#64596
30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Previous Next
Full log
Message #224 received at 64596 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: yantar92 <at> posteo.net, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 18:19:57 -0400
>
> > That's not all of the uses of this flag. Here's one example of other
> > uses:
> >
> > if (some_windows
> > && !f->redisplay
> > && !w->redisplay
> > && !XBUFFER (w->contents)->text->redisplay)
> > continue;
> >
> > (This avoids updating the tool bar and the tab bar of the frame, and
> > there's a similar condition that avoids updating the frame's title.)
>
> Right, but notice that what we're fundamentally checking is whether `w`
> (which is the frame's selected window here) needs to be updated, because
> that's the one currently "occupying" the tool-bar.
But testing the frame's redisplay flag will produce false positives,
because many changes that require to redraw the frame's windows don't
affect the tool bar or the frame's title.
> FWIW, I don't know why we don't also check
> `XBUFFER(w->contents)->redisplay` here.
We do:
if (some_windows
&& !f->redisplay
&& !w->redisplay
&& !XBUFFER (w->contents)->text->redisplay) <<<<<<<<<<<
continue;
> Also, I still don't see why that makes you think:
>
> frame's redisplay flag is what causes us to consider a frame in the
> first place.
>
> Indeed, a frame's redisplay flag may be such a reason, but a window's
> flag or its text buffer's may be the reason instead. A frame's
> `redisplay` flag does not need to be set for us to consider it.
No, my point is that fset_redisplay shouldn't set
windows_or_buffers_changed.
This bug report was last modified 1 year and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.