Re: RFC: (set-xkb-cyrillic-charset "koi8-r") for non-Mule XEmacs

MB> This model of computing is a very common one in the world of MB> character sets smaller than 128. MB> It's a very "low-tech" way of achieving a multi-lingual editor. A> That's exactly what we need. High-tech is already implemented and is A> called Mule :) MB> You can have a function that sets the font for a default face for MB> a buffer by using specifiers with MB> (set-face-font 'default "*koi8" (current-buffer)) A> That won't work because your buffer will have one-byte characters in A> 8859-5, and there is no way in non-Mule to have different font A> encoding and characters encoding. Moreover, your files will be in A> 8859-5 encoding. Moreover, you could not open koi8-r file and edit A> it. I mean that you would combine the set-face-font above with some method (explained in other messages) that would allows input to map keysyms to their koi8 code instead of their iso8859-5 code. A> Same shi^Wthing happens for some other languages I'm said (AFAIK, A> Czech have five commonly-used one-byte encodings, that's why Russian A> Apache is so popular there). Interesting. MB> This allows you to implement the command MB> (defun toggle-cyrillic-mode (&optional buffer) (interactive) ...) MB> this technique, combined with the keyboard-translate or MB> function-key-map mechanisms (and xmodmap, of course), allows you MB> to have a complete russian (or ukranian, or hungarian, etc.) MB> environment with very little lisp hacking. A> I just want to reuse code that's already there. Your code :) Although the key hacking code in C should be rewritten, there's enough functionality available to the lisp programmer that what you want can and should be implemented in lisp today. A .el file is much more shareable than a patch to the C code, that would require a potential user to rebuild their xemacs binary.