yet another XEmacs fork;-)
jcb+xeb at jcbradfield.org
Fri Nov 14 06:04:02 EST 2008
>AFAIK that's unacceptable in XEmacs proper since we intend to support
>Windows for the foreseeable future. Also, iconv (like MIME) doesn't
>properly distinguish between charsets and coding systems. I don't
>know if that's a problem for your design.
The devil's in the detail, for that one, I suspect.
>What's wrong with using the approach (and the code) from 21.5 that
>reads in a charset definition from a Unicode Consortium-format table?
>These are dumpable AFAIK.
Nothing, and that was my first thought. But then I thought that iconv
would have the advantage of making it easy to load the translation tables
on demand - why should I have 20MB (or however much it is) of
translation tables in main memory of every XEmacs instance, when my
typical instance only ever sees Latin-1 and maybe few dozen hanzi?
>Mule is not going away for a long time. Implementing the Unicode
>standard equivalents will be a lot of work, and I don't GNU has the
>resources to do it either, which means compatibility.
What's the definition of compatibility these days? I haven't used
fsfmacs for a decade or more, but my impression is that most
non-trivial elisp has to cater specially for fsfmacs and XEmacs. Is
More information about the XEmacs-Beta