Re: Bug 130397 (Was: Emacs - Ispell problem with i[no]german dictionary)

[Kenichi Handa]

In article <address@hidden>, Agustin Martin <address@hidden> writes:

> On Mon, May 17, 2004 at 02:06:58PM +0200, Agustin Martin wrote:
>>  My guess is that emacs is handling differently the 'è' character (In case of
>>  ancoding problems in the mail, it is the grave lowercase e `e) when typed in
>>  the address@hidden locale than when file is read or typed in the fr_FR 
>> locale.

> No news from upstream about this.

Sorry for the late respose.  I have overlooked your original
mail.  Your guess above is correct.  Emacs has multiple
different characters for e-grave.

> Having french selected as ispell default I do:
> 
> a) Start emacs with address@hidden locale and manually type
>    the (mispelled) french word déplorable. Try ispell-word
>    it. Bug reproduced, high bit is not considered a word
>    element.
>
> b) After previous step, I save the file containing that word and run emacs
>    on it again. ispell-word now works as expected and detects the complete
>    mispelled word proposing the right fix.
> 
> In both cases, emacs is called as
> 
> $ address@hidden emacs fr-test &
> 
> c) If I now type again the mispelled word after the previous one, previous
>    word is properly handled by ispell mode, but the bug is reproduced for
>    the just typed one. Also, both 'é' (previous and last one) clearly seem
>    to have a different look when using address@hidden However, if I
>    type it with a latin1 LC_ALL they look similar.
> 
> d) If I save the file and re-edit, ispell-word now works well on both words.
> 
> I have tested this with 'sid' Debian emacs21 (version 21.3+1-5)

Please try the same thing with the latest CVS code.  With
that, when you type e-grave in address@hidden locale, e-grave of
latin-iso8859-15 should be inserted in a buffer.  So, as far
as you are using a dictionary that uses iso-8859-15 encoding
(or in general, using a dictionary that uses the same
encoding as your locale), you should not face the above
problem.

> Seems that this problem is still present with sid emacs. Since sid
> dictionaries-common has ispell.el patched to allow any coding-system
> supported by emacs (including iso-8859-15 for {x}emacs21) I am considering
> a new ispell.el patch to workaround this latin0-latin1 unification problem.

> I am playing with redefining ispell-get-coding-system function in ispell.el
> so dict coding-system is changed to iso-8859-15 if was originally
> iso-8859-1 and emacs has iso-8859-15 as buffer-file-coding-system, something
> like

> ----------------------------------------
> (defun ispell-get-coding-system ()
>   (let (ispell-coding-system emacs-coding-system)
>     (setq ispell-coding-system
>         (nth 7 (assoc ispell-dictionary ispell-dictionary-alist)))
>     (setq emacs-coding-system
>         (coding-system-get buffer-file-coding-system 'mime-charset))
>     (if (and (string-equal emacs-coding-system "iso-8859-15")
>            (string-equal ispell-coding-system "iso-8859-1"))
>       emacs-coding-system
>       ispell-coding-system)))
> ----------------------------------------
>
> It seems to work for emacs21, but not for xemacs21 (seems a bug of this
> latter when giving the value of buffer-file-coding-system, just reported as
> #285990).
>
> This has the advantage that no special entries are needed for latin0 in the
> ispell-dictionary-alist.

At least you should check if buffer-file-coding-system is
nil or not before callding coding-system-get.  But, anyway,
I think the above function is too ad-hoc.  As iso-8859-1 and
iso-8859-15 contains different set of characters (even if
they are few), it's not good to treat them as the same
thing.

For instance, if a dictionary uses iso-8859-1 encoding, it
doesn't contain "\264" in CASECHARS entry.  But, if a
dictionary uses iso-8859-15 encoding, it should contain
"\264" (Z-WITH-CARON) in CASECHARS entry.

So, if you are going to check the spell of some word
containing Z-WITH-CARON by iso-8859-1 dictionary, something
goes wrong.

---
Ken'ichi HANDA
address@hidden