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: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: monnier <at> iro.umontreal.ca, 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 10:35:49 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: monnier <at> iro.umontreal.ca, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 07:28:09 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> BTW, is there any particular reason why windows_or_buffers_changed is
> >> not a queue of windows/buffer to be re-displayed?
> >
> > Why do we need such a queue, when the redisplay flags of buffers and
> > windows are supposed to tell us that already?
> 
> To not loop over all the existing windows and frames in xdisp.c:506
> redisplay branch.

Someone will have to demonstrate that this is worth our while.
Testing a single boolean flag is not an expensive operation, while
maintaining that queue also takes CPU.  Also, some changes in a window
can affect other windows on the same frame, for example if the window
is resized.

IOW, maybe it's a good idea and maybe it isn't, but it definitely
doesn't affect the most expensive parts of redisplay.

Previous Next

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