help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ispell.el and multilanguage lines.


From: Nikolay Kudryavtsev
Subject: Re: ispell.el and multilanguage lines.
Date: Mon, 7 Mar 2016 04:18:20 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Sorry, for the very late reply, was somewhat busy, plus this stuff required somewhat extensive extra checking.
Emacs doesn't yet have a concept of the language of the text,
certainly not when several languages are mixed in a buffer.
Ispell.el has CASECHARS and NOT-CASECHARS regular expressions in ispell-dictionary-alist. This should be enough for the purpose of differentiating Russian from English, if only it worked. But in practice, those regexps are not used correctly, since now ispell-get-line sends the whole line when re-search-forward finds CASECHARS within it. While I'd agree that the number of use cases, where CASECHARS and NOT-CASECHARS are useful is rather limited, fixing them seems easier than removing.

Yes, and the latest code base (of what will become Emacs 25.1)
supports this feature of Hunspell.
I've tried that version, sure it fixes this bug <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20495>, but I actually never had a problem with it in the first place, since you can avoid it in 24.5 by setting ispell-dictionary-alist manually after ispell-set-spellchecker-params had ran.

I believe that "mess" is fixed in the current code.  So I suggest you
try the latest emacs-25 branch.
There's a really confusing bug with the way hunspell behaves with Russian codepages on windows, that is not really emacs related. FYI: I'm using current hunspell from ezwinports. Let's start hunspell in windows cmd:
chcp 1251
hunspell -a "" -d ru_RU -i cp1251
тестовоеслово
testword
Both of the above would result in spellchecking failures. Let's add them to the personal dictionary:
*тестовоеслово
*testword
#
Now, if you try exiting and starting hunspell again, both words would be considered correct, since they are in your personal dictionary.

Here's where the bug comes into play. If you start some kind of bash, be it cygwin bash, or msys and try using hunspell there:
hunspell -a "" -d ru_RU -i utf-8
testword would check ok, but тестовоеслово would fail. The same would happen within emacs. My best guess is that this happens because of some locale-connected environmental variable, that bash(and emacs) sets.

So, in the end, I'm stuck with aspell and running one spellcheck per dictionary.

--
Best Regards,
Nikolay Kudryavtsev



reply via email to

[Prev in Thread] Current Thread [Next in Thread]