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

Previous Next

Package: emacs;

Reported by: Augusto Stoffel <arstoffel <at> gmail.com>

Date: Sun, 26 Feb 2023 14:57:02 UTC

Severity: normal

Tags: patch

Fixed in version 29.1

Done: Augusto Stoffel <arstoffel <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 2 years and 133 days ago.

Previous Next


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