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: Mon, 17 Jul 2023 08:53:00 -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.

Of course, we have loads of false positives.  The point of the
`redisplay` flags is just to rule out things we can easily rule out.
It's very coarse.  It could be made finer, of course.

> No, my point is that fset_redisplay shouldn't set
> windows_or_buffers_changed.

Setting `windows_or_buffers_changed` there is currently necessary in
order to make sure we look at the `redisplay` bits (as opposed to
updating only the selected window).


        Stefan

Previous Next

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