bug#74437: 30.0.92; completion-preview-idle-delay is delayed by flyspell

[Eli Zaretskii <eliz@gnu.org>]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 74437@debbugs.gnu.org,  mail@alternateved.com
> Date: Tue, 19 Nov 2024 21:16:56 +0100
> 
> >> -                           (accept-process-output ispell-process)
> >> +                           (accept-process-output ispell-process 1)
> >
> > Does this really work reliably from a timer?
> 
> I don't immediately see why it shouldn't, and the tests I tried so far
> seem to work, but your skepticism makes me wonder if there's anything
> I'm missing.  Do you have any particular potential issue in mind?

Not concretely, no.  But I see potential issues, since
accept-process-output enters a recursive wait_reading_process_output,
which could read output from other subprocesses, and timers affect how
frequently wait_reading_process_output loops.  So this should be
thoroughly tested in various scenarios.

> > You _are_ aware that this call to accept-process-output will run
> > timers while we wait?
> 
> Yes.  If that's a cause for concern, we can inhibit running timers here
> when we're calling flyspell-word from a timer, like in the patch below.

That's one measure, yes.  But it, too, should be thoroughly tested.

> > Also, what happens if there are other async
> > subprocesses running in parallel, like maybe Grep or compilation or
> > url-retrieve?
> 
> They make progress, which seems to work as expected, at least with Grep.
> That is if we use the previous patch, with the one below we pass non-nil
> JUST-THIS-ONE argument to accept-process-output when called from a timer
> so other processes shouldn't see new output during this call.  Either
> way works, AFAICT.

The question is: what do users expect to happen in those cases?