Tatsuya Kinoshita <[EMAIL PROTECTED]> writes:
> 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 :-/.)
> * 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).
> * 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.)
> * 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.
> * 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.]
> * setting utf-8 coding-priority is needed to prefer mule-ucs
That can be done (and undone) at any time.
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).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
