RE: 21.4.10-mule codings problem, ~ appears
>> x-symbol causes lots of problem reports with XEmacs/Mule.
Christoph> Stephen, if that is so[1], you should forward them to
Christoph> me.
OK.
Fine.
>> are not savable in the current encoding are present. You
can
>> get a similar effect by enabling the latin-unity package, but
>> it's limited (I think) to extended Latin characters.
Christoph> Well, it might be similar, but not very[2], and it
Christoph> would not prevent the ~ for the character `alpha'.
If it's a non-Latin character set (ie, private to x-symbol),
that's
quite possible.
BTW, XEmacs/latin-unity has the same bug as Emacs had before v 21.4 [1]
(to be released next year):
- it first tries to find a correct encoding
- it then runs the functions in `write-region-annotate-functions' / the
encode functions corresponding to `buffer-file-format'.
(see `write-region' of XEmacs-21.4.5, sorry if that has been corrected)
The opposite sequence is the correct one, since the _result_ chars, not
the _source_ chars of the annotatation/encoding are the characters
XEmacs must write.
Go ahead, try it.
I see, latin-unity also includes the safe-encoding mechanism. Sorry, I
didn't read the latin-unity info pages carefully enough, and I couldn't
use latin-unity with X-Symbol for the above mentioned reasons.
(The workaround for Emacs < 21.4 is to turn off the safe-encoding
mechanism for the characters which will be encoded by X-Symbol. I hope
there is a better one for XEmacs/latin-unity - I will check that after
the release of X-Symbol-4.4.4. Of course, what I really hope is that
the above mentioned XEmacs/latin-unity bug will be fixed...)
- Christoph
[1] A sufficient reason to drop support for Emacs < 21.4 as soon as
Emacs-21.4 is out.