MULE rant...

[David Kastrup]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> If you want my advice, it's to truncate the error string to the
> first character that _has_ to be printable ASCII _before_ you pass
> it to any XEmacs function, and go from there.  Then the code for
> picking the appropriate unicode-to-mule translation function that
> Aidan provided should work across XEmacsen, and for Emacs as well,
> and not trigger any latent Mule-UCS bugs.  This is still a
> heuristic, but the only encodings I know of where it is violated are
> 16/32-bit Unicode.

Well, I explained already that I don't care as much about Emacs
compatibility as I care to have _any_ working interface.  You gave
some good pointers.

It's not as easy as you make it out to be since the TeX strings can
decide on a byte level to be either verbatim or ^^xx forms, and I
would have to set the process-decoding to no-conversion to stand a
chance of fixing this timely with XEmacs.  With Emacs, I can instead
just let the process decode tentatively from utf-8, and only when the
strings don't match, encode to get the original byte stream, do the
substitutions, decode again.  I'll have to think about what to do best
here instead.

Your proposal basically is to do manual checks coded in Elisp on the
byte strings before daring to pass them into C.  It might be what I
have to do in the end, but it certainly does not sound like a recipe
for performance.  And of course this is only possible if I throw the
generating process into no-conversion at first and decode _everything_
explicitly after manual checks.  It's all far from being pretty.
XEmacs is not at fault for the principal ugliness of the task, but it
does not particularly offer relief.  With Emacs I had a few "phew,
this actually works, I am lucky" experiences which turn out to be
nullified by XEmacs.  Too bad.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum