Re: status of utf-8.el, etc [Re: Several serious problems]

[Kenichi Handa <handa@m17n.org>]

In article <rzq4rcby1t4.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>  As the testsuite revealed several bugs, before working on
>>  RC, I decided to fix them in HEAD at first.

I've just installed fixes in HEAD.   Could people please
test these customizalbe variables.
	unify-8859-on-encoding-mode
	unify-8859-on-decoding-mode
	utf-fragment-on-decoding
	utf-translate-cjk

>>  (1-2) utf-8-translate-cjk can never be turned off once
>>  turned on.

> I don't think it should be toggled;

Then, why do we have this now?
	(defcustom utf-translate-cjk nil ...)
As far as it's a customizalbe variable, one should be able
to turn it off.

> is there a reason you'd want to avoid it?

One may or may not want select-safe-coding-system to decide
utf-8 as the default for a buffer that contains CJK charsets
and etc.  I'm not sure.

> What it needs is to be made more flexible about how the
> translation is done, allowing you to prefer Chinese to Japanese, for
> instance.  Since people moan about the lack of CJK Unicode support, I
> hoped someone else would do such work but there's been zero interest
> as far as I know...

One reason of zero interest is perhaps that such a people is
already using Mule-UCS.

>>  (2-1) As utf-8-fragment-on-decoding and utf-8-translate-cjk are
>>  also applicable to utf-16, I cut off "-8" from them.

> The `utf-8' comes from them being in utf-8.el.  At least
> utf-8-fragment-on-decoding isn't actually specific to Unicode coding
> systems.

Sure.  If utf(-8)-fragment-on-decoding is non-nil, even if
unify-8859-on-decoding-mode is on, cyrillic-iso-8bit, etc
shouldn't decode characters into mule-unicode-*.  But, I
don't have a time to find a better name, and at least,
removing "-8" is better.

>>  (2-2) Make translation table names and their body
>>  char-tables different to avoid confusion.

> As far as I remember, some of the confusion goes away if these are
> assumed always to be present, and loaded in the right order.

Of course, by disabling the facility of turing them off, we
can make things simpler.  But, that is not the case at least
now.

> Some of those names don't seem right.  For instance,
> ucs-mule-to-mule-unicode isn't only used by utf-8/16 as far as I
> remember.

???  So, it doesn't contain "utf".

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