GNU bug report logs - #61814
[RFC] Asynchronous, jit-lock-based Flyspell

Previous Next

Full log

Message #20 received at 61814 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: eliz <at> gnu.org, 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Mon, 27 Feb 2023 10:58:43 +0100

On Mon, 27 Feb 2023 at 00:31, Yuan Fu wrote:

> Augusto Stoffel <arstoffel <at> gmail.com> writes:
>
>> On Sun, 26 Feb 2023 at 17:11, Eli Zaretskii wrote:
>>
>>>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>>>> Date: Sun, 26 Feb 2023 15:56:00 +0100
>>>> 
>>>> Also, one obvious glitch is that one gets JIT™ corrections for the word
>>>> being currently typed.  Before going on an writing some ugly logic to
>>>> avoid that, and since one can influence an overlay appearance when the
>>>> mouse pointer hovers it, I was wondering if there's something analogous
>>>> for the cursor.
>
> There is ‘cursor-sensor-functions’, but it requires
> ‘cursor-sensor-functions’ to be on.

Aha, that's the keyword I wanted to hear.  I had a vague recollection of
something like that.

>  IIUC you want the squiggly lines remain invisible until point leaves
> the overlay, right? You probably have thought of this, but what about
> simply checking whether there is any whitespace character between
> point and the word being checked, before creating the overlay? Would
> that work?

Yes.  I've actually now implemented a pre-command hook for that and it
doesn't look too bad.  So maybe requiring cursor-sensor is overkill
here.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.