reassign 690318 hunspell forwarded 690318 http://sourceforge.net/tracker/?func=detail&aid=3577183&group_id=143754&atid=756395 found 690318 1.3.2-4 thanks
2012/10/12 Yuri D'Elia <[email protected]>: > Package: dictionaries-common > Version: 1.12.10 > Severity: important > > On my system I'm using emacs23 along with hunspell. > I don't have the aspell/ispell packages installed. > > If I enable flyspell without changing dictionary (thus using the default > "american"), everything works. > > If I attempt to use M-x ispell-change-dictionary "american" (which should give > me the same results), emacs hangs, resulting in lossage (and thus the > "important" severity of the bug report). > > The last message that I see in the minibuffer is: > > Starting new Ispell process [hunspell::american] ... > > but the only option at this point is kill emacs. > hunspell is recognized correctly, but is probably called with the wrong > arguments? > > aspell works fine, but I'd rather use hunspell. Hi, thanks for the info I have been debugging this problem and noticed that this is caused by some problems with the way hunspell handle init version string in pipe mode, way that is not compatible with ispell and aspell. This causes Emacs not catching the error condition caused by missing dictionaries after failed hunspell initialization. You tried american, but current myspell.us does not register itself for use with Emacs, so unless you have a personal entry in your ~/emacs file it should fail with an error like ispell-init-process: Can't open affix or dictionary files for dictionary named "american". In pipe mode, hunspell sends the init string unconditionally as soon as it detects the -a switch, so Emacs thiks there is a process and unsuscessfully expects for output if there is an error. You should not see this error if you switch to a dict that is registered with Emacs ispell.el. I have filed a bug report upstream about this problem http://sourceforge.net/tracker/?func=detail&aid=3577183&group_id=143754&atid=756395 with this summary: We recently received this bug report at Debian, http://bugs.debian.org/690318. Note that debian ships hunspell 1.3.2. This seems related to a problem with init string in pipe mode. When looking at hunspell.cxx code I noticed another potencial problem for Emacs. Here goes a summary of noticed problems, * The string is gettextized. Emacs (and may be others) heavily rely in English format to get info like spellchecker version. This may not work with translated string. * In pipe mode hunspell.cxx outputs version string as soon as it detects the -a switch, even if hunspell is not properly started because of errors. This behavior is different from what ispell and aspell do and confuses Emacs (output that string only when hunspell has properly started), causing Emacs hang if a missing dictionary is selected. Emacs waits for more info after that string is received. This is what seems to trigger http://bugs.debian.org/690318. As mentioned there I have been playing with a proposed change that seems to work here in my tests (mostly with normal use under Emacs), although it is still not deeply tested. Please find attached a patch with my current changes. I am reassigning this bug report toi hunspell and marking it as forwarded upstream. Regards, -- Agustin
0001-Try-fixing-some-problems-with-init-string-in-pipe-mo.patch
Description: Binary data
