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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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