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

MB> Oh, Alexey, can't you do everything you need for koi8 without MB> hacking the C code, by doing simply: MB> ;;; koi8.el: (when (not (featurep 'mule)) (keyboard-translate MB> 'Cyrillic_hardsign 'ydiaeresis) ... ) A> I want to switch by whole arrays. A> First reason: there is already code `x_keysym_to_character' that works A> but just needs a clean well-defined hack to solve single simple A> problem (Stephen, I consider your concerns about overcyrillization). It would be easy to add some hack to allow the user to specify the translation from keysym to equivalent character in event-Xt.c. This can be implemented internally using a hash table. But I'm not all sure that doing this is a good idea, since it adds Yet Another Key Mapping Mechanism, when we already have so many. And I don't understand why the ones we have (specifically, function-key-map) don't do exactly what you want. You have to maintain a mapping table from keysyms to koi8 character codes in any case. Isn't it easier to have it in lisp code than C code? A> Second reason, more practical about why I want to deal with arrays: A> suppose we're setting cp1251 encoding for Cyrillic characters. We A> have A> (defun set-cyrillic-cp1251-encoding A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xDA) A> (set-keysym-translation 'Cyrillic_DZHE ?\0x8F)) A> After that we want to switch to koi8-r. We have: A> (defun set-cyrillic-koi8-r-encoding A> (set-keysym-translation 'Cyrillic_HARDSIGN ?\xFF) A> ;; because koi8-r does not have DZHE A> (set-keysym-translation 'Cyrillic_DZHE nil)) A> That is, we have to explicitly unset every keysym that could be A> supported by some other encoding and could not be supported by the A> encoding we're trying to set. This is very tedious IMHO and is better A> handled by A> char *cyrillic = cyrillic_koi8_r; I disagree about "tedious". The information about keysyms which should be mapped to nil has to be maintained in any case, so there is just as much code to maintain. And I don't think humans will notice the time taken by the computer to do the remappings. I disagree that we should have a specific C-level mechanism for koi8. The C code you are hacking in event-Xt.c is a fallback of last resort. It could actually have been implemented by simply populating global-map, but doing it in C the way we did was a small optimization of space and startup time, and reduces user confusion by not having global-map cluttered with key bindings for keys the user doesn't have.