[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
From: |
Augusto Stoffel |
Subject: |
bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell |
Date: |
Mon, 27 Feb 2023 10:58:43 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On Mon, 27 Feb 2023 at 00:31, Yuan Fu wrote:
> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> On Sun, 26 Feb 2023 at 17:11, Eli Zaretskii wrote:
>>
>>>> From: Augusto Stoffel <arstoffel@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.