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

[Aleksey Cherepanov]

On Sat, Feb 22, 2014 at 06:41:08PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 22 Feb 2014 20:02:17 +0400
> > From: Aleksey Cherepanov <aleksey.4erepanov@gmail.com>
> > Cc: agustin.martin@hispalinux.es, 16800@debbugs.gnu.org
> > 
> > > Your setup _might_ work the same, especially if you don't mix
> > > different languages in the same buffer.  But in general, your change
> > > does affect behavior.
> > 
> > I mix languages. I am pretty sure that my setup works the same.
> 
> Not in general, it isn't.  See below.

I agree.

Oh, not even for my setup. But for my setup together with my files.
I've got an example.

> > BTW solution around reduction of jump points does not not affect
> > faces: "nd" or "badnd" at the end of "good badnd good " does not call
> > spell check on the first "badnd".
> 
> Not sure I understand what you are saying here.  What "first badnd"?
> you have only one in this example.

"nd" does not cause spell check of "badnd". Another "badnd" at the end
does not cause spell check of the first "badnd".

> > Emacs words are language sensitive too.
> 
> But not in the same way as ispell/flyspell is.  The CASECHARS,
> NON-CASECHARS, and OTHERCHARS parameters of the dictionary are only
> taken into account by ispell/flyspell.

I think one could define a dictionary like: ("my" "[a]" "[^a]" "" ...)
So the only letter for flyspell words is "a". That way "qqaaqqaaqq" is
one word for emacs and two words with garbage around for flyspell. I
think my solution fails in such case.

So flyspell's set should be consisted of full emacs categories to make
my solution work. Code for emacs word boundaries is in category.h,
macro WORD_BOUNDARY_P. We could use regular search for bad setups and
word search for good setups. Though it does not seem trivial to check
if flyspell's dictionary setup is good for my solution.

Russian alphabet is not a full emacs (Unicode, I guess) category. The
full category is Cyrillic script (or even wider). My solution does not
work if there is a letter from the complement (for instance, Lje
02131) right near my mis-spelling word. So I was wrong about the
behaviour: it is not the same, I just do not see differences in my
files.

We could mix: regular search for short distance and word search for
longer distance. Though it seems ugly for me.

I still think that we could make regexps with word boundaries
according to flyspell's meaning of word.

Thanks!

-- 
Regards,
Aleksey Cherepanov