Subject: bug#79306: Broken follow-mode

From: Eli Zaretskii <[email-masked]>
Date: Thu, 04 Sep 2025 09:15:51 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: Juri Linkov <[email-masked]>,  [email-masked]
> 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?