GNU bug report logs - #16800
24.3; flyspell works slow on very short words at the end of big file

Previous Next

Full log

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

From: Agustin Martin <agustin.martin <at> hispalinux.es>
To: Aleksey Cherepanov <aleksey.4erepanov <at> gmail.com>
Cc: 16800 <at> debbugs.gnu.org
Subject: Re: bug#16800: 24.3; flyspell works slow on very short words at the
 end of big file
Date: Fri, 21 Feb 2014 15:38:55 +0100

On Fri, Feb 21, 2014 at 12:15:00PM +0200, Eli Zaretskii wrote:
> > From: Aleksey Cherepanov <aleksey.4erepanov <at> gmail.com>
> > Date: Wed, 19 Feb 2014 00:56:45 +0400
> > 
> > I faced a problem editing my big .org file (2mb+) with flyspell-mode
> > enabled. I edit it every day, regularly mistype and get words of one
> > or two letters that are wrong in Russian and cause flyspell work slow.
> > 
> > This one-liner produces "good" file to reproduce the bug.
> > perl -e 'print(((join " ", ("met and") x 10) . "\n") x 30000)' > t.txt
> > 
> > Typing "nd" at the end of file gives a huge pause even on a fast
> > computer. But "mw" or "md" does not give pauses because they are not
> > substrings in this file. It is repeatable with emacs -Q.
> 
> This seems to be due to the Flyspell's feature of recognizing
> duplicates of mis-spelled words, and, if found, highlighting such
> duplicates in a different face.  If you customize the variable
> flyspell-duplicate-distance to some small value (or even zero), the
> delay goes away.  Evidently, with the default value of -1, Flyspell
> searches all the way to the beginning of the giant buffer, looking for
> a duplicate of "nd".
> 
> Interestingly, I don't see this when the speller is Ispell, but I do
> see it with Hunspell.  Not sure how using Ispell avoids this problem.

Hi,

On the other hand, I can reproduce this also with ispell, as well as with
aspell and hunspell.

On Wed, Feb 19, 2014 at 12:56:45AM +0400, Aleksey Cherepanov wrote:
> flyspell-duplicate-distance variable on its own could mitigate the
> problem but it changes the behaviour so I do not want to use this  
> variable.

For the records, I was playing with a customized value of 50000 for that
distance and even if there is still a minor delay it is reasonable. I am
in a fast box, do not know in other boxes.

> I tried to patch flyspell-word-search-backward and
> flyspell-word-search-forward functions from flyspell.el replacing
> search-backward with word-search-backward and search-forward with
> word-search-forward (perl -pe 's/\(search-/(word-search-/' ). It
> solved the problem but I do not know what it broke.
> 
> I expect problems with this solution because I do not know if
> flyspell's meaning of word is the same as emacs' one. I think it is
> described in flyspell-get-word function that is called after search-*
> in the patched functions.

I have never played with Emacs syntax tables, but  I'd expect differences
only if there is a mismatch between chars in OTHERCHARS and non
alphabetic chars that Emacs considers as possible parts of a word. 

Regards,

-- 
Agustin

Previous Next

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