Re: unicode-internal status
Aidan Kehoe wrote:
Ar an cúigiú lá déag de mí na Samhain, scríobh Ben Wing:
> > It's not _that_ widespread, since non-Mule XEmacs wouldn't honour it,
as I
> > understand it.
>
> btw "remove this assumption" means using calls to (make-char ...) instead
of
> literal characters.
Note that doing that to, say, the Quail input methods (which are, of course,
not in core) will make them much less maintainable. Not that they’re
especially maintained as is.
well, what i've actually done when i changed things is to leave the
original characters inside of comments.
btw in some cases switching to make-char makes things more maintainable
[at least for me] ... e.g. i have no visual clue that such-and-such
character is meant to be latin-3 rather than latin-1. also, in the
weirder charsets, e.g. indian-1-column, all i see are ~'s anyway.
> [...] so i've also created some unicode charsets for
old-mule; these cover
> everything up through 0x2FFFF and should take care of your problem to some
> extent. (i rearranged the handling of leading bytes so any private leading
> byte can be for charsets of any size, so less issues with running out of
> charset space.) if i assign appropriate ISO2022 final bytes, or implement
> the ISO2022 extension mechanism, these can be reliably stored in
> byte-compiled code.
Thanks!
> (but this problem only arises if the source .el file is in utf-8, *and*
> we use escape-quoted for the .elc file, *and* you have literal characters
> embedded in your .el file. are these all true?)
Yes. (It’s an input method, it makes it a lot more maintainable when you can
see what a sequence of characters maps to.)
Auto-save files use escape-quoted for much the same reason as does the byte
compiler--because it was a universal coding system for Mule--and will have
encountered the same problem.
hmm. i actually invented escape-quoted and put things in for the same
reason you're citing, but i'd forgotten about that. i think i'll go
ahead and use the extension mechanism.
Lisp hackers; how do I evaluate some code only at byte-compile time?
The
below assertion fails both at compile time and run time.
(eval-when-compile
(assert (not t)
t
"This file should not be compiled;
The UTF-8 to escape-quoted mapping is not stable from one XEmacs invocation
to the next, in my JIT-UTF-8 implementation. Since byte-compiled files use
escape-quoted, this will break."))
> the use of the extension mechanism is more standard and less hackish but
> with the former method, current 21.5 versions of xemacs can at least load
> the files without puking, since they create unknown iso charsets on the
> fly. probably we don't really care about such compatibility in any case.