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: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Fri, 14 Jul 2023 18:56:06 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 10:20:32 -0400
> 
> `prevent_redisplay_optimizations_p` is just another of those vars.
> The problem with that var is not its existence but the fact that by now
> noone knows what it means, so we can't touch that code, basically :-(

I think we can touch that code, but we need to do it carefully, and we
need to leave behind a "fire escape".

If you look at its uses (not where the flag is set, but where it is
checked), you will see that it either disables some optimization
(example: in try_window_id), or sets other variables, like
current_matrix_up_to_date_p.  In the first case, we need to go over
the places where the flag is set to true and think whether those
setters indeed need to disable each particular optimization.

In the second case, I think the flag is basically used to quickly
disable optimizations conditioned by those other variables, in a way
that prevents us to make more expensive tests.

If we understand better each of these cases -- and there aren't so
many of them -- we then could discuss whether to set the flag or not
and whether to replace it with something else, whether those are
other, more descriptive, flags or nothing.

Previous Next

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