bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell

[Yuan Fu]

> On Mar 4, 2023, at 3:41 AM, Augusto Stoffel <arstoffel@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