bug#69733: [PATCH] Flyspell (flyspell-word): do not force 'save-excursion' on timers

[Eli Zaretskii]

> From: Daniel Pettersson <daniel@dpettersson.net>
> Cc: 69733@debbugs.gnu.org
> Date: Fri, 15 Mar 2024 12:29:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks, but I'm still confused regarding what you are trying to fix
> > and why you are trying to fix it with the patch you proposed.
> 
> Lets just preface with that for accept-process-output non idle timers
> and process filters are the same thing, right?  So any filter or timer
> might run inside of accept-process-output if JUST-THIS-ONE is nil.
> 
> The issue was noticed with the elpa package dape, with
> flyspell-prog-mode.  But I was able to reproduce it in gdb-mi.el
> (gud-next) as well.  The common denominator here is moving the point
> from filter/timer functions, in both cases source buffers. 

I think (and you agree below) that these are bugs in these packages.
Non-idle timer cannot safely move point, and neither can a process
filter.  It basically means we move point while the user might be
typing something, which would be a terrible misfeature!

> > First, AFAIU, save-excursion is there because flyspell-get-word might
> > move point.  So this is justified.
> 
> No doubt that the save-excursion is justified but it surly does not need
> to wrap everything, one could be a bit more exact (wrap those parts)
> that actually move the point.

That's correct, so if you want to move save-excursion closer to
flyspell-get-word, it would be fine.

> After some thinking I it might be impossible to impose anything on the
> caller of accept-process-output.  And the bug is in dape and gdb-mi.el
> that gud should call gud-display-line inside of an idle timer to ensure
> that the point is moved, if I understand how idle timers are called
> which might be false.

Exactly.  Idle timers can move point, provided that they wait a
reasonable amount of idleness time, to avoid interpreting a 0.01 sec
gap in user typing as "idle".

> Maybe it would be a good idea if "(elisp) Timers" would mention these
> things.  Would that be an good idea?

Yes, I think so.  We already advise not to do certain things in a
timer function, so this could be an addition to those parts.

> I could be up for writing something up, even if don't consider
> myself to be that good at writing documentation.

Thanks, please do.