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

Alexey> In this case first clause should be (it should modify Alexey> cyrillic_koi8_r[] that is stored somewhere in some hashtable Alexey> and used by x_keysym_to_character(): SJT> That's what I wanted to avoid. OK, I see that it's probably SJT> unavoidable in no-mule. And it's probably right to do it inside SJT> that switch (this automatically makes it configurable according SJT> to character set, SJT> so that the iso-to-koi translation does NOT get SJT> applied in the Latin-2 buffer, which would really hinder a SJT> Polish/Russian translator). A> Just for clarity: there is no "iso-to-koi" translation here and no A> concept of "Latin-2 buffer". I speak of non-Mule, and there is only A> one-to-one translation between internal representation (single byte), A> font encoding and external representation (bytes in files). It is A> very common kind of setup AFAIK. A> We just need to implement various translations between Cyrillic_XXX A> and those one-byte encodings. This model of computing is a very common one in the world of character sets smaller than 128. It's a very "low-tech" way of achieving a multi-lingual editor. The original developers of Multilingualization in Emacs targetted Japanese, for which the hack of using the 128-256 range of character codes doesn't work. So the low-tech way is not supported as well as it could be. But it's also so simple not much support is needed. You can have a function that sets the font for a default face for a buffer by using specifiers with (set-face-font 'default "*koi8" (current-buffer)) This allows you to implement the command (defun toggle-cyrillic-mode (&optional buffer) (interactive) ...) this technique, combined with the keyboard-translate or function-key-map mechanisms (and xmodmap, of course), allows you to have a complete russian (or ukranian, or hungarian, etc.) environment with very little lisp hacking. Mule does give you some extra benefits, but there's a price to pay.