Anybody with feelings about this, please let us know!
Alan Mackenzie writes:
Thanks, I understand that now. Maybe --with-mule should be made the
Yes, I think you're right. People who need the speed will know it and
usually are the kind of folks who build their own and mess with CFLAGS
on the configure command-line. :-)
Ah. I would presume there's not a lot of call for a non-Mule
I wouldn't go so far as to say that. People can and do process
gigabyte log files with XEmacs, for example. If 99.44% of it is
ASCII, the few non-ASCII characters rarely matter and if necessary you
can iconv them in a Unicode terminal. But what the 0.56% do to
char-byte position translation speed is a vicious hate crime.
Nevertheless, I think the "if you need it, you have the option"
argument is pretty strong.
The other thing is that with Xft builds, it probably should be
relatively easy to make no-mule XEmacs Unicode *display-capable*
without making it Unicode edit-capable. (The complex parts of Mule at
the C level are buffer position translations and coding systems.) The
theory is that Xft already knows how to interpret UTF-8, I think (if
not, the translation to UTF-16 is trivial and code probably already in
all 21.5 builds). So there would be a special UTF-8 buffer display
mode, which would provide overlays to hide the UTF-8 representation
and display the Unicode glyphs, and a simple function to pipe to iconv
(or other character code translation program such as GNU recode).
XEmacs-Beta mailing list