[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: |
Eli Zaretskii |
Subject: |
bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) |
Date: |
Thu, 13 Jul 2023 22:03:20 +0300 |
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 64596@debbugs.gnu.org
> Date: Thu, 13 Jul 2023 17:19:29 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The purpose of force-mode-line-update is to do what its name says,
> > regardless of whether the buffer was modified or not, and how it was
> > modified. The idea is that Lisp programs which change something that
> > they know must affect the mode line call this function to make sure
> > the mode line is redrawn with up-to-date information.
>
> I do not claim that I fully understand
Who does, when it comes to the display code?
> but what is confusing is that a number of other places in code
> simply use bset_update_mode_line without disabling optimizations. In
> particular:
>
> 1. kill-all-local-variables
> 2. rename-buffer
bset_update_mode_line is for a single buffer, whereas the FIXME is for
the case where force-mode-line-update is called with a non-nil ALL
argument.
> Also, `force-window-update' disable optimizations for a given window,
> but not when all windows should be updated - in contrast with the code
> in OP.
When all the windows need to be updated, we force that via
windows_or_buffers_changed, which is a somewhat stronger flag, as far
as preventing optimizations goes.
> So, `force-window-update' and `force-mode-line-update' are at least
> inconsistent.
Why should they be entirely consistent? They do different jobs.
bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Stefan Monnier, 2023/07/13