RFC: -- default configure to --with-mule

Anybody with feelings about this, please let us know! Alan Mackenzie writes: 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. :-) 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 XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta