bug#16800: 24.3; flyspell works slow on very short words at the end of big file

[Eli Zaretskii]

> Date: Fri, 21 Feb 2014 15:38:55 +0100
> From: Agustin Martin <agustin.martin@hispalinux.es>
> Cc: 16800@debbugs.gnu.org
> 
> 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.

What behavior does it change?  Do you really care to have a
mis-spelled word be highlighted in a different face just because
there's an identical mis-spelling half a megabyte away?

> 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 would suggest to change the default to something finite, like 20000
perhaps.  Having it set to -1 by default is IMO unwieldy, since
buffers can be very large.

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

And this doesn't change behavior?  See below.

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

The effect depends on the language, I think.