Re: decode-char & utf-8-fragment-on-decoding

[Kenichi Handa]

In article <rzqd6rtuy5g.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> 
writes:
> Kenichi Handa <handa@etl.go.jp> writes:
>>  Thank you.  It seems to be the right fix.  I'll install it
>>  soon.   Dave, do you see any problem with that?

> Yes, I think it's wrong.  I think the only bug is that the doc string
> of `utf-8-fragment-on-decoding' is missing the normal `setting it
> directly does not take effect' text for a Custom option with a setter.
> It has no effect on how decoding is done, and `decode-char' was meant
> to be consistent with how utf-8 decoding actually works.

> The translation table is always used -- CCL has no way to access Lisp
> variables anyway.  It only matters how it's populated (empty by
> default).

I see your point.  Ok, I'll cancel the change, and add this
sentence:
        Setting this variable outside customize has no effect.
in the docstring of utf-8-fragment-on-decoding.

So, we should regard it a feature that
        (decode-char 'ucs (encode-char C 'ucs))
will not return C even if C belongs to one of mule-unicode-*
charsets.

---
Ken'ichi HANDA
handa@etl.go.jp