MULE rant...

[Stephen J. Turnbull]

>>>>> "David" == David Kastrup <dak at gnu.org> writes:

    David> In order to display unicode in menus, I convert Unicode
    David> character positions in AUCTeX using decode-char for
    David> display.

Too bad.  That function doesn't exist in XEmacs.  I'm sure it could be
made to work, but it doesn't as of this moment.  It only works with
mule-ucs.

    David> Bad.  Even worse is that when loads mucs.el manually (where
    David> it is defined), that decode-char will not work, presumably
    David> because some Unicode tables also don't get autoloaded.

The tables don't get loaded because mucs.el is not the official
interface.  un-define.el is.

Anyway, since when does any Emacs autoload data?  AFAIK only functions
autoload.

You have to use the whole 9 yards of mule-ucs, which is unsupported
and unmaintained because nobody here understands it (or anywhere else;
only Ken'ichi Handa and Hisashi Miyashita have the necessary knowledge
of CCL, and I believe Handa-san prefers to do Unicode stuff in C).  To
the best of my knowledge, it has been abandoned by Miyashita (its
author) as well.  I will go check and see if mule-ucs can be updated,
but I doubt that the particular features you need will ever be available.

The fact is that Unicode is only minimally supported in XEmacs 21.4.
All we really wanted to support there was decode-coding-region and
friends, and mule-ucs does that well enough.  For most purposes,
mule-ucs has been sufficient.  Unfortunately, it's not something that
can be improved by the XEmacs developers, and it has been replaced by
something completely different in XEmacs 21.5.

    David> Try, for example, (decode-coding-string "\200abc" 'utf-8)

Current XEmacs (21.5) returns "\200abc".

    David> I am getting to a state as package maintainer where I
    David> increasingly lose even an idea how I could make things work
    David> with UTF-8 under XEmacs even if I tried very hard.

You probably can't with a reasonable amount of effort.  In XEmacs 21.4
it requires use of the mule-ucs package, which evidently misbehaves
when you feed it broken UTF-8 (why do you need to do that, anyway?)
mule-ucs will almost certainly not get any better, so you're going to
need to hack around its weaknesses if you support XEmacs 21.4.

In XEmacs 21.5 you will almost certainly see a fair amount of
divergence until the next major GNU Emacs synch because our internals
are quite different from those of GNU Emacs.  Since emacs-unicode is
as yet far from "done", I don't know that it will happen any time
soon.

I don't really see this as a problem specific to XEmacs; it sounds
like GNU Emacs isn't much better, except that you're used to its
brokenness.  True, it does have a bunch of nasty hacks to support
Unicode natively better than XEmacs 21.4 does, but those aren't enough
to come close to what mule-ucs or XEmacs 21.5 provide.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.