On December 2, 2005 at 10:51AM +0000, fx (at gnu.org) wrote: > > BTW, the current mule-ucs startup is for various reasons: > > > > * un-define is needed for utf-* on emacs21/xemacs21 > > There isn't a problem just loading `un-define'. That doesn't redefine > decode-char/encode-char. (I should have said that is probably only a > problem in Emacs, since XEmacs doesn't have those functions.) > However, the package loads `unicode', which does cause the trouble. > That should certainly not be necessary if you only want mule-ucs for > the coding systems it defines. (I haven't heard of anyone apart from > himi who understands it well enough to do anything else :-/.)
`jisx0213' requires `mucs', and `mucs' redefines {en,de}code-char
and causes problems, such as (decode-char 'ucs #x00B7) -> nil.
Loading `unicode' prevents it.
However, your report mentions that loading `unicode' is not a
complete solution.
> > * loading un-define after other packages might cause problems
>
> In what way? I can't think how it would cause problems (apart from
> possible conflict with ucs-tables, but that could happen anyway).
At least, bitmap-mule on emacs20 failed if un-define wasn't loaded
early in startup. However, emacs20 is no longer exists in Debian...
> > * loading ucs-tables after un-define might cause problems
>
> It is actually preloaded in the current Emacs. (Loading it after the
> Debian mule-ucs startup might fail, since it uses decode-char.)
Ah, right.
> > * unify-8859-on-encoding-mode is usefull even if un-define is loaded
>
> I thought that mule-ucs managed to do essentially the same thing,
> though I've forgotten the details. However, I think they will give
> inconsistent results with the find-coding-systems-... functions.
I felt that unify-8859-on-encoding-mode's unification for
iso-8859-* is a good thing than mule-ucs's unification.
> > * unify-8859-on-decoding-mode conflicts with un-define
>
> [Just for my information, what is the conflict? I don't know whether
> I ever looked at that when I did ucs-tables.]
mule-ucs's unification seems to depend on legacy charset (such as
latin-iso8859-*). However, unify-8859-on-decoding-mode prefer
mule-unicode-* rather than the legacy charset. So, if
unify-8859-on-decoding-mode is enabled, mule-ucs is unusable for me.
> > * setting utf-8 coding-priority is needed to prefer mule-ucs
>
> That can be done (and undone) at any time.
You are right.
I thought that prefering mule-ucs's utf-8 than emacs's mule-utf-8
is better for users if un-define is enabled in startup.
> The most important thing is that loading the package should not
> clobber {en,de}code-char (or other Emacs functions -- I haven't
> checked for others).
I agree with it.
BTW, next release of Emacs (22.1) supports utf-* (includes CJK),
mule-ucs is proving troublesome, and the mule-ucs upstream
development is not active. I cannot recommend mule-ucs at this time.
Anyway, I'll reconsider the mule-ucs startup.
Thanks,
--
Tatsuya Kinoshita
pgpPVmyxpZ83g.pgp
Description: PGP signature
