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

Previous Next

Package: emacs;

Reported by: Aleksey Cherepanov <aleksey.4erepanov <at> gmail.com>

Date: Tue, 18 Feb 2014 20:59:02 UTC

Severity: normal

Found in version 24.3

Fixed in version 24.5

Done: Agustin Martin <agustin6martin <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aleksey Cherepanov <aleksey.4erepanov <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16800 <at> debbugs.gnu.org, agustin.martin <at> hispalinux.es
Subject: bug#16800: 24.3;	flyspell works slow on very short words at the end of big file
Date: Sat, 22 Feb 2014 20:02:17 +0400
On Sat, Feb 22, 2014 at 03:10:02PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 22 Feb 2014 16:44:13 +0400
> > From: Aleksey Cherepanov <aleksey.4erepanov <at> gmail.com>
> > Cc: Agustin Martin <agustin.martin <at> hispalinux.es>, 16800 <at> debbugs.gnu.org
> > 
> > Also GNU coding standards say to avoid arbitrary limits (parts 2.1
> > and 4.2).
> > http://www.gnu.org/prep/standards/standards.html
> 
> This limit is not arbitrary.

Anyway it is a limit that could be avoided.

> > > > > 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.
> > 
> > No, it seems that my setup works the same. See below.
> 
> 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.

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

> > The difference is in word bounds. We are in trouble if flyspell's word
> > on its ends does not have ends of emacs' word. If flyspell's word has
> > ends of emacs' word on its ends and even contain them inside then we
> > are ok (try to search "a b" over "aa bb a b aa bb"). So could ends of
> > flyspell's word do not match with ends of emacs' word?
> 
> Yes, definitely.  See what flyspell-get-word does to find where the
> word begins and where it ends.  Flyspell's "words" are
> language-sensitive, whereas Emacs's words are not.

I saw this function.

Emacs words are language sensitive too. Emacs jumps through all ends
of words from RU and EN languages even if the words are not separated.

Example:
Word of 3 parts: English "asdf", Russian "фыва" (execute-kbd-macro
(kbd "C-q 02104 RET C-q 02113 RET C-q 02062 RET C-q 02060 RET")),
English "asdf".

asdfфываasdf
^   ^   ^   ^
b   b   b
    f   f   f

M-b and C-M-r \< jumps through positions marked by b. M-f and
C-M-r \> jumps through positions marked by f. It is one word for
flyspell in my setup and in LANG=C emacs -Q.

But I do not know if it is applicable to other languages and/or other
setups. How could it be improved? Other solutions?

I'd propose as a variant to use emacs' words for flyspell and vice
versa but it would a bad idea. My emacs jumps over asdf'asdf in one
hop and similar behaviour could be done for other languages with their
respective 'otherchars' but it would be inconvenient for some users
including me (python-mode has _ as a part of word by default, both
questions how to enable it everywhere and how to disable it in
python-mode exist).

Thanks!

-- 
Regards,
Aleksey Cherepanov




This bug report was last modified 10 years and 137 days ago.

Previous Next


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