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: Wed, 20 Nov 2024 16:52:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Eshel Yaron <me@eshelyaron.com>
> >> Cc: 74437@debbugs.gnu.org,  mail@alternateved.com
> >> Date: Tue, 19 Nov 2024 21:16:56 +0100
> >
> >> > 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?
> 
> I don't know

Neither do I.  I didn't say something was wrong with either of these
implementations, I'm just saying they should be well tested by users
before we have enough basis to make the decisions whether the idea is
generally good and whether it should probably become the default in
some future version.