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
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 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
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]
