GNU bug report logs -
#74437
30.0.92; completion-preview-idle-delay is delayed by flyspell
Previous Next
Full log
Message #41 received at 74437 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 74437 <at> debbugs.gnu.org, mail <at> alternateved.com
>> Date: Wed, 20 Nov 2024 16:52:49 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> 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
>> >
>> >> > 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.
Sounds good. So here's a full patch that keeps the current
implementation as the default:
[0001-New-option-flyspell-delay-use-timer.patch (text/x-patch, attachment)]
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.