bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: detect-coding-string doesn't return all possibilities


From: Kenichi Handa
Subject: Re: detect-coding-string doesn't return all possibilities
Date: Thu, 13 Mar 2003 20:34:27 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

Sorry for the late reply.

In article <m3smtw31uq.fsf@defun.localdomain>, Jesper Harder <harder@ifa.au.dk> 
writes:
> `detect-coding-string' doesn't return all possible coding systems for a
> string.  For example:

> (detect-coding-string (encode-coding-string "안녕" 'korean-iso-8bit))
> => (iso-latin-1 iso-latin-1 raw-text chinese-big5 no-conversion)

> Clearly korean-iso-8bit is a possible coding system, but this is not
> detected.

detect-coding-string doesn't return all possible coding
systems, but returns a possible coding systems Emacs may
automatically detect in the current language environment.

Result of (encode-coding-string "안녕" 'korean-iso-8bit) is
a sequence of bytes of the range 0xA0..0xFF.

For instance, if you are in "Latin-1" language environment,
such a byte sequence is detected as iso-latin-1.  If you are
in "Korean" language environment, it is detected as
korean-iso-8bit, and in that case, detect-coding-string
returns this: (korean-iso-8bit iso-latin-1 raw-text
chinese-big5 no-conversion)

But the docstring of detect-coding-system is surely not
good.  I've just changed the first paragraph as this.  How
is it?

Return a list of possible coding systems used on decoding a byte
sequence containing the bytes in STRING when the coding system
`undecided' is specified.  The list is ordered by priority decided in
the current language environment.

---
Ken'ichi HANDA
handa@m17n.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]