Re: RFC: generic support for single-byte encodings in non-Mule XEmacs

Hrvoje> Alexey Mahotkin <alexm(a)hsys.msk.ru&gt; writes: Hrvoje> That cannot by right because the value of that property is Hrvoje> a character, not a byte. For instance, under Mule, it Hrvoje> works perfectly for Japanese characters. How about 'buffer-representation? Yes, the elements of a buffer are always characters, but using "character" drags a lot of stuff (coded character sets, in particular) with it. Hrvoje> [...] Hrvoje> I take it that you would like to automatize these mappings Hrvoje> according to a new concept of "single-byte encodings", Hrvoje> present in the absence of Mule? [...] Hrvoje> Also, all of this sounds like an idea for a first-class Hrvoje> external package. Write it and distribute it to all your Hrvoje> friends. If it becomes immensely popular and all of Hrvoje> Russia starts using it, we'll include it too. It's as Hrvoje> simple as that. I agree with this. I think that probably you can and should do all of this with a package. The package could work with Mule by simply forcing all file I/O to 'binary, I bet. If the package fails in some boundary cases (which I think is highly likely, for the reasons Hrvoje gives among others), well, that's the way packages (don't) work. The core has to do better. Except for one thing. There's no reason to wait for your package to become immensely popular; we can include it immediately. :-) The various changes that you are talking about are surely not going to get in to 21.1 any other way, and not 21.4, either. They are not bug fixes to implementation, they are design changes at least, and arguably new features. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."