[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Several serious problems
From: |
Kenichi Handa |
Subject: |
Re: Several serious problems |
Date: |
Mon, 26 Aug 2002 22:17:58 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Richard Stallman <address@hidden> writes:
> I'm quite confused with the current status of utf-8.el,
> ucs-tables.el, utf-16.el, utf-8-subst.el, etc in HEAD and
> RC.
> Do you understand the situation in HEAD?
I don't understand what exactly do you mean by "situation".
I don't know if they are the same as what Dave currently
has.
I understand how each functions and variables are supposed
to work. And, I know that those codes doesn't do definitely
wrong thing by reading through the codes briefly.
But, I have not checked if they surely works as
expected. I believe Dave has done it.
And, I don't understand why those many functions/variables
are designed as the current way. For instance,
(1) Why does loadup.el has this code:
(ucs-unify-8859 'encode-only)
instead of:
(unify-8859-on-encoding-mode 1)
(2) Why doesn't utf-8-subst.el provide mappings of
non-Chinese characters for ksc, gb, and jisx charsets?
The document of utf-8-translate-cjk says as below:
----------------------------------------------------------------------
Whether the `mule-utf-8' coding system should encode many CJK characters.
Enabling this loads tables which enable the coding system to encode
characters in the charsets `korean-ksc5601', `chinese-gb2312' and
`japanese-jisx0208', and to decode the corresponding unicodes into
...
----------------------------------------------------------------------
but, currently only Chinese characters in those charsets are
handled.
(3) Why is utf-8-translate-cjk a variable, not a minor-mode
like unify-8859-on-(de/en)coding-mode? Or, why the
latter is not a simple variable? By the way, it seems
that once we customize utf-8-translate-cjk to t,
customize it back to nil doesn't cancel the translation.
(4) It seems that the variable name
utf-8-fragment-on-decoding is not appropriate because it
is used also in utf-18.el. Perhaps,
ucs-fragment-on-decoding is better.
(5) It seems that mule-utf-16 can handle the same range of
characters as mule-utf-8, but `safe-charsets' property
doesn't contain, for instance, `latin-iso8895-2'.
Perhaps, this is simply a bug to be fixed easily.
---
Ken'ichi HANDA
address@hidden
- Re: Several serious problems, (continued)
- Re: Several serious problems, Dave Love, 2002/08/29
- Re: Several serious problems, Richard Stallman, 2002/08/30
- Re: Several serious problems, Dave Love, 2002/08/29
- Re: Several serious problems, Richard Stallman, 2002/08/30
- Re: Several serious problems, Dave Love, 2002/08/31
- Re: Several serious problems, Richard Stallman, 2002/08/30
Re: Several serious problems, Richard Stallman, 2002/08/24
Re: Several serious problems, Dave Love, 2002/08/29