Re: Converting a Mule character to UCS code point

"Stephen J. Turnbull" <[email protected]> writes:

>     Hrvoje> * char-to-ucs, part of the mule-ucs package
>
> This is really the only current option in 21.4.

Why?  `encode-char' works as well, and is part of the same
(unsupported) package that char-to-ucs comes from.  Am I missing
something?

> mule-ucs is deprecated, orphaned, and available only because there's
> no reasonable way to get Unicode support in 21.4.

However, it does seem to work for my (admittedly simple) purpose.

>     Hrvoje> * encode-char, also part of the mule-ucs package, and also
>     Hrvoje> present in FSF.  The interface is a bit weird
>     Hrvoje> (`(encode-char CHAR 'ucs)'), but it seems to work
>     Hrvoje> correctly.
>
> Dunno about this.  It's not weird to me.  Presumably you can do that
> for any charset and get the external code point.

Indeed presumably.  Check again.  :-)

>     Hrvoje> Can any of these be considered stable?
>
> char-ucs is, although if GNU Emacs is standardizing on encode-char,
> I guess we have to turn around and piss with the wind.  You should
> ask Handa and/or Love.  Here's a trivial restriction of the
> encode-char interface for 21.5:
>
> (unless (fboundp 'encode-char)
>   (defun encode-char (ch charset)
>     (if (eq charset 'ucs)
>         (char-ucs ch)
>       (error 'wrong-type-argument "encode-char only supports ucs" charset))))

Of course, I don't want to define encode-char, I'll use my own
namespace.  But this code will fail under 21.4 where encode-char can
*become* available at any time and where `char-ucs' is quite useless.
What I do right now is something like:

(if (and (fboundp 'encode-char)
         (encode-char char 'ucs))
    ;; Code that relies on `encode-char' being available.
  ;; Code that doesn't.
  )

That is, I handle both `encode-char' missing and returning nil.

What I want to know is, will XEmacs 21.5 break this by moving away
from `encode-char' to `char-ucs'?