From: Kenichi Handa <handa@m17n.org>
Cc: lionel@mamane.lu, emacs-devel@gnu.org, 130397@bugs.debian.org
Subject: Re: Bug 130397 (Was: Emacs - Ispell problem with i[no]german dictionary)
Date: Wed, 22 Dec 2004 21:37:32 +0900 (JST) [thread overview]
Message-ID: <200412221237.VAA07262@etlken.m17n.org> (raw)
In-Reply-To: <20041217121515.GA2270@agmartin.aq.upm.es> (message from Agustin Martin on Fri, 17 Dec 2004 13:15:15 +0100)
In article <20041217121515.GA2270@agmartin.aq.upm.es>, Agustin Martin <agustin.martin@hispalinux.es> 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 fr_FR@euro 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 fr_FR@euro 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
>
> $ fr_FR@euro 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 fr_FR@euro 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 fr_FR@euro 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
handa@m17n.org
next prev parent reply other threads:[~2004-12-22 12:37 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.43.0305140821370.30166-100000@wr-linux02.rki.ivbb.bund.de>
[not found] ` <m3addpd2ur.fsf@dionysos.nib>
[not found] ` <E19HNCh-0000tv-00@fencepost.gnu.org>
[not found] ` <20040517120658.GA6919@agmartin.aq.upm.es>
[not found] ` <E1BQ5z5-0000f4-5u@fencepost.gnu.org>
2004-05-19 11:44 ` Bug 130397 (Was: Emacs - Ispell problem with i[no]german dictionary) Agustin Martin
2004-05-21 8:01 ` Agustin Martin
2004-12-17 12:15 ` Agustin Martin
2004-12-22 12:37 ` Kenichi Handa [this message]
2004-12-22 17:13 ` Agustin Martin
2005-01-04 12:50 ` Kenichi Handa
2005-01-04 14:55 ` Bug 130397 Stefan
2005-01-05 2:00 ` Kenichi Handa
2005-01-05 4:42 ` Stefan Monnier
2005-01-05 5:50 ` Kenichi Handa
2005-01-05 14:02 ` Stefan Monnier
2005-01-06 0:44 ` Kenichi Handa
2005-01-06 16:30 ` Ken Stevens
2005-01-06 17:33 ` Stefan Monnier
2005-01-07 0:39 ` Kenichi Handa
2005-01-07 15:48 ` Agustin Martin
2005-01-08 12:31 ` Geoff Kuenning
2005-01-08 12:47 ` David Kastrup
2005-01-08 13:29 ` Miles Bader
2005-01-08 17:15 ` Geoff Kuenning
2005-01-10 4:45 ` Eli Zaretskii
2005-01-10 9:09 ` David Kastrup
2005-01-10 20:16 ` Eli Zaretskii
2005-01-13 7:50 ` Kenichi Handa
2005-01-08 22:39 ` Peter Heslin
2005-01-07 15:36 ` Agustin Martin
2005-01-07 20:29 ` Ken Stevens
2005-01-07 21:27 ` Juri Linkov
2005-01-13 5:59 ` Kenichi Handa
2005-01-18 10:44 ` Juri Linkov
2005-01-18 13:57 ` Geoff Kuenning
2005-01-19 7:34 ` Juri Linkov
2005-01-19 12:22 ` Geoff Kuenning
2005-04-29 0:29 ` Geoff Kuenning
2005-04-29 8:45 ` Thien-Thi Nguyen
2005-01-18 23:24 ` Kenichi Handa
2005-01-19 7:43 ` Juri Linkov
2005-01-19 12:52 ` Kenichi Handa
2005-01-19 13:08 ` David Kastrup
2005-01-07 15:34 ` Bug 130397 (Was: Emacs - Ispell problem with i[no]german dictionary) Agustin Martin
2005-01-10 13:06 ` Lionel Elie Mamane
2005-01-10 17:16 ` Agustin Martin
2005-01-11 5:16 ` Kenichi Handa
2005-01-11 19:56 ` Agustin Martin
2005-01-11 21:39 ` Lionel Elie Mamane
2005-01-12 7:37 ` Kenichi Handa
2005-01-12 19:17 ` Agustin Martin
2005-01-13 5:53 ` Kenichi Handa
2005-01-11 14:29 ` Richard Stallman
2005-01-12 7:45 ` Kenichi Handa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200412221237.VAA07262@etlken.m17n.org \
--to=handa@m17n.org \
--cc=130397@bugs.debian.org \
--cc=emacs-devel@gnu.org \
--cc=lionel@mamane.lu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).