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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61814 in the body.
You can then email your comments to 61814 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sun, 26 Feb 2023 15:56:00 +0100

[Message part 1 (text/plain, inline)]

Tags: patch

Find attached an attempt to make Flyspell talk to the spell checking
process outside of the main command loop using jit-lock.

To activate this mode of operation one should set 'flyspell-synchronous'
to nil before turning Flyspell on.

Not many of the numerous Flyspell options are supported, but hopefully
this can be considered useful even without covering all of them.  In any
case, let me know what you consider to be the essentials.

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.

[0001-Async-Flyspell.patch (text/patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sun, 26 Feb 2023 17:11:40 +0200

> 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.

I'm not sure I understand the problem: just don't spell-check the word
at point and don't put any overlays there, and that's all.  Right?
Bonus points for doing this for the word at point only when the last
command was one of a list of known commands, like self-insert-command,
delete-char, yank, etc.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sun, 26 Feb 2023 16:36:58 +0100

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.
>
> I'm not sure I understand the problem: just don't spell-check the word
> at point and don't put any overlays there, and that's all.  Right?

Writing just any old code that achieves the result is easy.  Writing the
simplest and most elegant version sometimes requires much more work.  I
asked a specific question about overlays because knowing the answer
would help me in the latter endeavor.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sun, 26 Feb 2023 17:45:20 +0200

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 61814 <at> debbugs.gnu.org
> Date: Sun, 26 Feb 2023 16:36:58 +0100
> 
> 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.
> >
> > I'm not sure I understand the problem: just don't spell-check the word
> > at point and don't put any overlays there, and that's all.  Right?
> 
> Writing just any old code that achieves the result is easy.  Writing the
> simplest and most elegant version sometimes requires much more work.  I
> asked a specific question about overlays because knowing the answer
> would help me in the latter endeavor.

I'm sorry I annoyed you by trying to be helpful.  I will shut up now.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Augusto Stoffel <arstoffel <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 00:31:19 -0800

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. 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?

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.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Yuan Fu <casouri <at> gmail.com>, eliz <at> gnu.org, 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sat, 04 Mar 2023 12:41:16 +0100

After using this for some time, I realized that not everybody will
prefer "JIT spellcheking" of the entire screen over the well-known
Flyspell behavior.  Given that the Flyspell code is a bit difficult to
generalize, it seems better to keep the alternative as a separate
package.

It also seems best, at least initially, to develop the new package
independently as an ELPA package.

Stefan, could you add the following to ELPA?  I'll then add a README,
fix the headers, and make a release.

  https://github.com/astoff/jit-spell

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

From: Yuan Fu <casouri <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: eliz <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Sat, 4 Mar 2023 14:59:41 -0800

> On Mar 4, 2023, at 3:41 AM, Augusto Stoffel <arstoffel <at> gmail.com> wrote:
> 
> After using this for some time, I realized that not everybody will
> prefer "JIT spellcheking" of the entire screen over the well-known
> Flyspell behavior.  Given that the Flyspell code is a bit difficult to
> generalize, it seems better to keep the alternative as a separate
> package.
> 
> It also seems best, at least initially, to develop the new package
> independently as an ELPA package.
> 
> Stefan, could you add the following to ELPA?  I'll then add a README,
> fix the headers, and make a release.
> 
>  https://github.com/astoff/jit-spell

Right, I’ve tried wucuo.el before, which spell checks every word currently displayed in the window, so it shows warnings on words far from point. And I found myself preferring flyspell’s behavior of only showing warnings on words I just typed or moved over.

wucuo.el also caused an issue when I opened a buffer with some inline images. The inline image is the raw image data encoded in base64 inserted into the file as a string, plus a display text property over the whole string displaying it as the image. wucuo.el thinks that huge string is visible in the window (because of the display text property), and tries to spell check that huge string, and got stuck.

I wonder if it’s possible or desirable to follow the flyspell’s behavior but make it async? Preferably when some mechanism to discard unnecessary spell checks. For example, I modified my scrolling functions to inhibit flyspell from running in post-command-hook, which speeds up scrolling considerably. Otherwise flyspell would try to spell check every word you scrolled by and cause perceivable slow-down.

Yuan

Message #29 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, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Mon, 06 Mar 2023 11:52:53 +0100

On Sat,  4 Mar 2023 at 14:59, Yuan Fu wrote:

> wucuo.el also caused an issue when I opened a buffer with some inline
> images. The inline image is the raw image data encoded in base64
> inserted into the file as a string, plus a display text property over
> the whole string displaying it as the image. wucuo.el thinks that huge
> string is visible in the window (because of the display text
> property), and tries to spell check that huge string, and got stuck.

wucuo.el seems to be synchronous like Flyspell, so that sounds like a
big problem.

Anyway, which major mode does that?  AFAIK the usual is to have the
underlying text of an image just a space or something similar.

> I wonder if it’s possible or desirable to follow the flyspell’s
> behavior but make it async? Preferably when some mechanism to discard
> unnecessary spell checks. For example, I modified my scrolling
> functions to inhibit flyspell from running in post-command-hook, which
> speeds up scrolling considerably. Otherwise flyspell would try to
> spell check every word you scrolled by and cause perceivable
> slow-down.

It sure is possible, but not something I would be interested in doing.
jit-spell shouldn't suffer from the issue you described.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: casouri <at> gmail.com, monnier <at> iro.umontreal.ca, 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Mon, 06 Mar 2023 14:15:32 +0200

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  eliz <at> gnu.org,
>   61814 <at> debbugs.gnu.org
> Date: Mon, 06 Mar 2023 11:52:53 +0100
> 
> On Sat,  4 Mar 2023 at 14:59, Yuan Fu wrote:
> 
> > wucuo.el also caused an issue when I opened a buffer with some inline
> > images. The inline image is the raw image data encoded in base64
> > inserted into the file as a string, plus a display text property over
> > the whole string displaying it as the image. wucuo.el thinks that huge
> > string is visible in the window (because of the display text
> > property), and tries to spell check that huge string, and got stuck.
> 
> wucuo.el seems to be synchronous like Flyspell, so that sounds like a
> big problem.
> 
> Anyway, which major mode does that?  AFAIK the usual is to have the
> underlying text of an image just a space or something similar.

Just visit any image file with "C-x C-f", and you will see this in
action.

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

From: Juri Linkov <juri <at> linkov.net>
To: Yuan Fu <casouri <at> gmail.com>
Cc: eliz <at> gnu.org, Augusto Stoffel <arstoffel <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Tue, 07 Mar 2023 20:25:19 +0200

> I wonder if it’s possible or desirable to follow the flyspell’s behavior
> but make it async? Preferably when some mechanism to discard unnecessary
> spell checks. For example, I modified my scrolling functions to inhibit
> flyspell from running in post-command-hook, which speeds up scrolling
> considerably. Otherwise flyspell would try to spell check every word you
> scrolled by and cause perceivable slow-down.

There is a patch proposed recently in bug#61874 that does this.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: eliz <at> gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 61814 <at> debbugs.gnu.org
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Tue, 7 Mar 2023 16:45:49 -0800

> On Mar 6, 2023, at 2:52 AM, Augusto Stoffel <arstoffel <at> gmail.com> wrote:
> 
> On Sat,  4 Mar 2023 at 14:59, Yuan Fu wrote:
> 
>> wucuo.el also caused an issue when I opened a buffer with some inline
>> images. The inline image is the raw image data encoded in base64
>> inserted into the file as a string, plus a display text property over
>> the whole string displaying it as the image. wucuo.el thinks that huge
>> string is visible in the window (because of the display text
>> property), and tries to spell check that huge string, and got stuck.
> 
> wucuo.el seems to be synchronous like Flyspell, so that sounds like a
> big problem.
> 
> Anyway, which major mode does that?  AFAIK the usual is to have the
> underlying text of an image just a space or something similar.
> 
>> I wonder if it’s possible or desirable to follow the flyspell’s
>> behavior but make it async? Preferably when some mechanism to discard
>> unnecessary spell checks. For example, I modified my scrolling
>> functions to inhibit flyspell from running in post-command-hook, which
>> speeds up scrolling considerably. Otherwise flyspell would try to
>> spell check every word you scrolled by and cause perceivable
>> slow-down.
> 
> It sure is possible, but not something I would be interested in doing.
> jit-spell shouldn't suffer from the issue you described.

Great!

Yuan

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Yuan Fu <casouri <at> gmail.com>, 61814 <at> debbugs.gnu.org, eliz <at> gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Wed, 08 Mar 2023 09:50:14 +0100

On Tue,  7 Mar 2023 at 20:25, Juri Linkov wrote:

>> I wonder if it’s possible or desirable to follow the flyspell’s behavior
>> but make it async? Preferably when some mechanism to discard unnecessary
>> spell checks. For example, I modified my scrolling functions to inhibit
>> flyspell from running in post-command-hook, which speeds up scrolling
>> considerably. Otherwise flyspell would try to spell check every word you
>> scrolled by and cause perceivable slow-down.
>
> There is a patch proposed recently in bug#61874 that does this.

Two administrative questions:

- Can/should I as the initiator of this ticket close it, given that it's
  resolved?

- Is the use of this list to discuss bugs in ELPA packages encouraged or
  rather not?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: casouri <at> gmail.com, 61814 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 juri <at> linkov.net
Subject: Re: bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
Date: Wed, 08 Mar 2023 15:57:19 +0200

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Yuan Fu <casouri <at> gmail.com>,  eliz <at> gnu.org,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  61814 <at> debbugs.gnu.org
> Date: Wed, 08 Mar 2023 09:50:14 +0100
> 
> Two administrative questions:
> 
> - Can/should I as the initiator of this ticket close it, given that it's
>   resolved?

Yes, please.  But you (or anyone else) can also close any other bug
that has been resolved, you don't need to be the initiator for that.

> - Is the use of this list to discuss bugs in ELPA packages encouraged or
>   rather not?

Discussing ELPA bugs here is OK.

Previous Next

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