Bug#341593: mule-ucs: package clobbers encode-char and decode-char
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]
Bug#341593: mule-ucs: package clobbers encode-char and decode-char
On December 2, 2005 at 10:51AM +,
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
Bug#341593: mule-ucs: package clobbers encode-char and decode-char
Package: mule-ucs Severity: important I'm not sure whether this should be higher severity than `important' -- it affects other packages. In particular, nxml-mode now conflicts with mule-ucs because of this issue, but it shouldn't need to. The mule-ucs startup sucks in the library `mucs', which redefines `encode-char' and `decode-char'. These are fairly fundamental in multilingual handling, and they no longer work properly. E.g. (decode-char 'ucs #xfffe) = nil Firstly, these definitions should be renamed (or possibly advised so that they try the mule-ucs stuff if the normal functions return nil). Secondly, I don't think the startup should pull in the support libraries anyway. They aren't needed for just defining the utf coding systems. The startup could define what it needs in compiled code -- the four versions of `un-define' that it basically wants (`jisx0213-flag' × `prefer-latin-flag') -- and choose one at run time. Also, I'm surprised the startup turns on unify-8859-on-encoding-mode. I'd expect that to conflict with mule-ucs, but I haven't checked what actually happens now. I don't think the un-define-style code should be turned on by default; I see you've rejected that already in #312883, but I don't understand the comments about it. On the SPARC I just tried, mule-ucs adds 25s to Emacs startup. It doesn't really help that the development Emacs makes mule-ucs mostly obsolete, since there's no sign of it even becoming stable :-(. -- System Information: Debian Release: 3.1 APT prefers stable APT policy: (900, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-sparc64 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341593: mule-ucs: package clobbers encode-char and decode-char
On December 1, 2005 at 3:27PM +, fx (at gnu.org) wrote: Package: mule-ucs Severity: important I'm not sure whether this should be higher severity than `important' -- it affects other packages. In particular, nxml-mode now conflicts with mule-ucs because of this issue, but it shouldn't need to. The mule-ucs startup sucks in the library `mucs', which redefines `encode-char' and `decode-char'. These are fairly fundamental in multilingual handling, and they no longer work properly. E.g. (decode-char 'ucs #xfffe) = nil Firstly, these definitions should be renamed (or possibly advised so that they try the mule-ucs stuff if the normal functions return nil). Secondly, I don't think the startup should pull in the support libraries anyway. They aren't needed for just defining the utf coding systems. The startup could define what it needs in compiled code -- the four versions of `un-define' that it basically wants (`jisx0213-flag' × `prefer-latin-flag') -- and choose one at run time. Also, I'm surprised the startup turns on unify-8859-on-encoding-mode. I'd expect that to conflict with mule-ucs, but I haven't checked what actually happens now. I don't think the un-define-style code should be turned on by default; I see you've rejected that already in #312883, but I don't understand the comments about it. On the SPARC I just tried, mule-ucs adds 25s to Emacs startup. It doesn't really help that the development Emacs makes mule-ucs mostly obsolete, since there's no sign of it even becoming stable :-(. Thanks for the report. I rejected the request about loading speed issue (#312883). However, your report mentions that loading mule-ucs causes other important problems. I'll reconsider the mule-ucs startup issue. BTW, the current mule-ucs startup is for various reasons: * un-define is needed for utf-* on emacs21/xemacs21 * loading un-define after other packages might cause problems * loading ucs-tables after un-define might cause problems * unify-8859-on-encoding-mode is usefull even if un-define is loaded * unify-8859-on-decoding-mode conflicts with un-define * setting utf-8 coding-priority is needed to prefer mule-ucs * etc... -- Tatsuya Kinoshita pgpXEO3NhrbUd.pgp Description: PGP signature
