[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug 130397
Re: Bug 130397
Wed, 5 Jan 2005 14:50:09 +0900 (JST)
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)
Stefan Monnier <address@hidden> writes:
> But ispell.el should be able to automatically check whether the chars can be
> safely encoded with the coding-system and if not (as in your example),
> ispell.el will know that the word can't be checked by ispell and should
> just be skipped (and maybe marked as "uncheckable").
That seems to be a good approach. But, just checking
whether the chars is encodable with the coding-system is not
enough. For instance, entry for "francais" dict doesn't
contain "ñ" in CASECHARS, but "español" is safely encodable
by iso-8859-1. So, the same error happens. For ispell.el
to know that "español" is uncheckable, we anyway need the
current database ispell-dictionary-alist.
By the way, isn't it possible to make that database
automatically from *.aff?
>> 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.
> Then string-to-multibyte sounds like a safer choice.
> `string-as-multibyte' has very strange semantics, I recommend we avoid it as
> much as possible.
Ok, I agree with using string-to-multibyte here.
- 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, 2005/01/04
- Re: Bug 130397, Stefan Monnier, 2005/01/04
- Re: Bug 130397,
Kenichi Handa <=
- 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
- Re: Bug 130397, Miles Bader, 2005/01/09
- Re: Bug 130397, Geoff Kuenning, 2005/01/09