[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: |
Thu, 13 Jul 2023 13:20:23 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> `force-mode-line-update' has the following FIXME:
>
> if (!NILP (all))
> {
> update_mode_lines = 10;
> /* FIXME: This can't be right. */
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
> else if (buffer_window_count (current_buffer))
> {
> bset_update_mode_line (current_buffer);
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
>
> This FIXME has been introduced in 655ab9a3800, shortly after
> ecda65d4f7e, which moved this code from `set-buffer-modified-p'.
ecda65d4f7e changed `force-mode-line-update` from
(if all (with-current-buffer (other-buffer)))
(set-buffer-modified-p (buffer-modified-p)))
to
if (!NILP (all) || buffer_window_count (current_buffer))
{
update_mode_lines = 10;
current_buffer->prevent_redisplay_optimizations_p = 1;
}
That new code was (to the best of my knowledge) doing the same as what
the old ELisp code did (I got to that code basically by taking the sum
of the C code run by the original ELisp code and then simplifying it by
eliminating those things which canceled each other).
That code already had the same problem as the one I flagged with the
FIXME: when we do (force-mode-line-update t) the effect should be
global, so if `prevent_redisplay_optimizations_p` is needed in
`current_buffer` it should be needed in other displayed buffers as well.
> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> situation when the modification flag is unset in the buffer, but the
> buffer was actually modified, and has to be redrawn.
> If my understanding is correct,
> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
I strongly suspect it doesn't belong in `force-mode-line-update`, indeed.
> Stefan will tell, but I'm quite sure he wrote that FIXME because
> removing that line caused regression in some situation.
Nope. I put the FIXME simply because I realized that the code doesn't
make sense: if that line is sometimes necessary, then I'm pretty sure it's
not always sufficient.
Stefan
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), (continued)
bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update),
Stefan Monnier <=
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Eli Zaretskii, 2023/07/13
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Ihor Radchenko, 2023/07/13
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Stefan Monnier, 2023/07/13
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Eli Zaretskii, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Stefan Monnier, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Eli Zaretskii, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Stefan Monnier, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Ihor Radchenko, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Eli Zaretskii, 2023/07/14
- bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update), Eli Zaretskii, 2023/07/15