[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61814: [RFC] Asynchronous, jit-lock-based Flyspell
From: |
Yuan Fu |
Subject: |
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@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