GNU bug report logs -
#74437
30.0.92; completion-preview-idle-delay is delayed by flyspell
Previous Next
Full log
View this message in rfc822 format
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 74437 <at> debbugs.gnu.org, mail <at> 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?
This bug report was last modified 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.