GNU bug report logs -
#79306
Broken follow-mode
Previous Next
Full log
Message #14 received at 79306 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Juri Linkov <juri <at> linkov.net>, 79306 <at> debbugs.gnu.org
> Date: Thu, 04 Sep 2025 00:58:34 -0400
>
> > Is it allowed to perform redisplay from pre-redisplay-function?
>
> Yeah, I think `pre-redisplay-function` is still early enough that it
> happens before we start messing with the state, so it's safe. I guess
> that means it can be called with a normal `call` rather than
> `safe_call`.
>
> > If so, we need to refine the above test, or maybe disable it when we
> > call pre-redisplay-function.
>
> Agreed. Maybe with something like the patch below?
I guess so (but we need a comment there explaining the reason for not
calling dsafe_call). And why didn't you bind inhibit_quit?
One other thing we should perhaps consider: before you introduced the
redisplay_counter thing, redisplay_internal would in this case return
immediately at the beginning:
/* I don't think this happens but let's be paranoid. In particular,
this was observed happening when Emacs shuts down due to losing X
connection, in which case accessing SELECTED_FRAME and the frame
structure is likely to barf. */
if (redisplaying_p)
return;
In case of follow-mode, this means the call to 'redisplay' in
follow-adjust-window would previously do nothing.
So the change you propose will avoid the top-level throw, but it might
produce behavior in follow-mode that is different from what we had in
Emacs 30. I don't use follow-mode, so I don't know what that could
cause, but maybe someone who does could run with the patch and see if
anything unexpected happens?
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.