Re: [HELP] Problem with Mule-UCS

[Dave Love <d.love@xxxxxxxx>]

>>>>> "JR" == Jason Rumney <jasonr@xxxxxxx> writes:

 JR> The end user should not need to be concerned about the internal
 JR> representation, so I don't think this should be necessary. 

Perhaps not, but it typically makes a difference whether or not you
can actually display characters.

 JR> With the current internal representation of characters in Emacs,
 JR> there are benefits to using the "traditional" Mule internal
 JR> representation where possible (the ability to save a file in a
 JR> non-Unicode based coding system, for example).

That's only a question of doing the translation on encoding.  See my
unification code for 8859-N.

 JR> I cannot think of any benefits of using the new mule-unicode-*
 JR> internal representation for Mule-UCS.

It makes it easier to get consistent display, e.g single-column box
drawing characters.  Try Kuhn's UTF-8 demo in default Mule-UCS, for
instance, versus the result when preferring mule-unicode over the
double-width CJK charsets.

 JR> It is also used by the default utf-8 support in Emacs-21, but
 JR> that is a bit of a hack compared to what Mule-UCS provides.

I don't understand why so, not that I have anything against Mule-UCS.