[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug 130397
From: |
Kenichi Handa |
Subject: |
Re: Bug 130397 |
Date: |
Wed, 5 Jan 2005 11:00:11 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3.50 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Stefan <address@hidden> writes:
>> Hmmm, then how about the attached patch to the latest CVS
>> emacs? With that, all equivalent charaters (e.g a-grave in
>> all laitn-X) should be handled well. This patch will be
>> applicable also to Emacs 21.3 but not yet tested in that
>> version.
> Can someone explain to me why ispell.el needs those kinds of things?
> My vague understanding is that ispell.el needs to know which chars are part
> of a word and that in the past (pre-MULE), this had to be redefined for each
> and every language since the codes 128-255 could mean completely
> different things.
> Why can't ispell.el just use the `w' syntax to decide what is a word and
> then rely on the decoding/encoding to do the rest of the work?
> That would fix the problem where a word like "expérience" is checked as two
> words if the dictionary is "american".
That will cause another problem. For instance, when we have
"español" in a buffer and the ispell dictionary is czech
(latin-2), as "español" is encoded into "espa?ol" by
latin-2, it causes the error "Ispell and its process have
different character maps" because ispell returns the result
of two words "eapa" and "ol".
>> + ;; Char-table that maps an Unicode character (charset:
>> + ;; latin-iso8859-1, mule-unicode-0100-24ff) to
>> + ;; a string in which all equivalent characters are listed.
>> +
>> + (defconst ispell-unified-chars-table
>> + (let ((table (make-char-table 'ispell-unified-chars-table)))
>> + (map-char-table
>> + #'(lambda (c v)
>> + (if (and v (/= c v))
>> + (let ((unified (or (aref table v) (string v))))
>> + (aset table v (concat unified (string c))))))
>> + ucs-mule-8859-to-mule-unicode)
>> + table))
> All the elements of this table should be multibyte strings.
> For this, we may need to wrap the (string X) into
> (string-to-multibyte (string X))
As `c' and `v' are always multibyte characters, (string X)
always return a multibyte string.
>> + (string-as-multibyte
>> + (mapconcat
>> + #'(lambda (c)
>> + (let ((unichar (aref ucs-mule-8859-to-mule-unicode c)))
>> + (if unichar
>> + (aref ispell-unified-chars-table unichar)
>> + (string c))))
>> + str ""))))
> Do you expect the output of mapconcat to be unibyte and to contain
> emacs-mule encoding of multibyte chars?
No. STR may be an ASCII-only string, in which case, the
result of mapconcat is a unibyte ASCII-only string. I'd
like to change it to a multibyte ASCII-only stirng to avoid
converting STR again and again in such a case.
---
Ken'ichi HANDA
address@hidden
- Re: Bug 130397 (Was: Emacs - Ispell problem with i[no]german dictionary), Kenichi Handa, 2005/01/04
- Re: Bug 130397, Stefan, 2005/01/04
- Re: Bug 130397,
Kenichi Handa <=
- Re: Bug 130397, Stefan Monnier, 2005/01/04
- Re: Bug 130397, Kenichi Handa, 2005/01/05
- Re: Bug 130397, Stefan Monnier, 2005/01/05
- Re: Bug 130397, Kenichi Handa, 2005/01/05
- Re: Bug 130397, Ken Stevens, 2005/01/06
- Re: Bug 130397, Stefan Monnier, 2005/01/06
- Re: Bug 130397, Kenichi Handa, 2005/01/06
- Re: Bug 130397, Agustin Martin, 2005/01/07
- Re: Bug 130397, Geoff Kuenning, 2005/01/08
- Re: Bug 130397, David Kastrup, 2005/01/08