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 a Hrvoje> character, not a byte. For instance, under Mule, it works perfectly Hrvoje> for Japanese characters. Hrvoje> The name `ascii-character' sucks for the same reason -- it's not Hrvoje> necessarily ASCII. Historically it was ASCII, and that property was Hrvoje> used to communicate that TAB should insert ?\t, etc. Agreed. Hrvoje> The one thing that bugs me about this is that it's introducing yet Hrvoje> another abstraction ("single-byte"), and one which has no equivalent Hrvoje> in Mule whatsoever. That's IMHO a very bad thing, which will Hrvoje> undoubtedly lead to maintenance and documentation problems. ("I Hrvoje> compiled XEmacs with Mule, and my single-byte stuff no longer works!") Agreed. Hrvoje> Now that Mule has been hacked into something close to usability, I Hrvoje> must admit I doubt that what you propose it worth the maintenance Hrvoje> pain. Can you remind me why exactly Mule fails to work for you? Agreeed. Hrvoje> Also, all of this sounds like an idea for a first-class external Hrvoje> package. Write it and distribute it to all your friends. If it Hrvoje> becomes immensely popular and all of Russia starts using it, we'll Hrvoje> include it too. It's as simple as that. Alexey: In any case, it is not obvious exactly what the user will want. Perhaps users will want to use koi8 in one buffer, alternativnij in another. Then your `global-set-key's need to change to `local-set-key'. (Unfortunately, the `ascii-character' property is a global thing, which would tend to hinder implementing this kind of functionality.) This again suggests that everything should be implemented in elisp.