Menu

#104 ~ prefixed strings are treated as words in pipe mode

open
None
5
2009-03-07
2009-02-19
No

Noticed a funny problem with extended character mode
when using hunspell and emacs ispell.el. While is
properly ignored when invoked from the command line
(ispell -T option), seems to be processed as another
word when set from inside the pipe, that is, when
receiving something like ~latin1,

---------------------------------------------------------------------
$ echo "~latin1
aaa" | hunspell -a -d es_ES
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.2.8)
& latin 13 1: latín, litan, latina, latine, latino, latiné, latinó, latan, laten, latir, latid, latió, latón

& aaa 8 0: asa, ara, ala, ata, ama, aba, aja, aya
---------------------------------------------------------------------

According to the hunspell man page,

A line starting with '~' causes hunspell to set
internal parameters (in particular, the default
string character type) based on the filename given
in the rest of the line.

So it should behave as expected or be ignored if this
feature is unsupported.

One consequence of this is that emacs ispell.el gets
confused, and when trying to spell-check a word in a
dictionary having something like ~latin1 in the
default ispell.el entry, always check the word latin
instead of the intended word. Running ispell-region
results in a misalignment error.

Using hunspell 1.2.8

Best wishes, and thanks for your work

Discussion

  • Németh László

    • assigned_to: nobody --> nemethl
     
  • Németh László

    Thanks for the report. The original ispell feature hasn't been implemented despite the manual.

     
  • Agustin Martin Domingo

    Thanks for the reply.

    I did not expect a real implementation of the original ispell feature, just that such ~ prefixed words be ignored in pipe mode. I do not know of any language with words containing '~'.

    If you think that the original ispell feature should not be implemented for hunspell, an alternative is to modify Emacs ispell.el to not send that strings for hunspell. Otherwise, just using symlinks to the {.aff,dic} with the names ispell.el expects may not work if ispell.el contains an extended-character-mode value for that dict. Of course there is always the alternative of setting an entry for hunspell in `ispell-local-dictionary-alist' for Emacs.

    Regards,