this is what i call the "russian c-x problem". at one point i had worked out what the correct thing to do is, and there are various comments to this effect in XEmacs; but i never finished it. it looks like aidan went ahead and implemented it, though, right, aidan? in events.h we have: enum alternative_key_chars { KEYCHAR_CURRENT_LANGENV, KEYCHAR_DEFAULT_USER, KEYCHAR_DEFAULT_SYSTEM, KEYCHAR_UNDERLYING_VIRTUAL_KEY_CURRENT_LANGENV, KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_USER, KEYCHAR_UNDERLYING_VIRTUAL_KEY_DEFAULT_SYSTEM, KEYCHAR_QWERTY, KEYCHAR_LAST }; struct Lisp_Key_Data { #ifdef EVENT_DATA_AS_OBJECTS struct lrecord_header lheader; #endif /* EVENT_DATA_AS_OBJECTS */ /* What keysym this is; a character or a symbol. */ Lisp_Object keysym; /* Modifiers held down when key was pressed: control, meta, etc. Also includes buttons. For many keys, Shift is not a bit; that is implicit in the keyboard layout. */ int modifiers; /* Alternate character interpretations for this key in different keyboard layouts. This deals with the problem of pressing C-x in the Russian layout (the so-called "Russian C-x problem"), for example: `x' gets mapped to a Cyrillic character, so what do we do? For that matter, what about `C-x b'? What we do is look the key up in the default locales (current language environment, user default, system default), then check to see if the underlying virtual key is alphabetic in the same three defaults, then finally check US ASCII. We ignore the underlying virtual key for the current layout to avoid the problem of a French speaker (AZERTY layout) who temporarily switches to Russian: The virtual keys underlying Russian are US-ASCII, so what the French speaker things of as C-a (the key just to the right of TAB) appears as C-q. I've just implemented this in event-stream.c, and I really want to see feedback from actual Russians about it, and whether it needs to be much more complete than what I've done. E.g, the mapping back to US Qwerty is hardcoded on the X11 side of things, and only deals with the alphabetic characters. Also, I think it's downright confusing for people with Roman letters on their keyboard to have random other letters than are described as calling some command, call that command. So I want to consider enabling it by language environment. [[ (#### We should probably ignore the current char and look *ONLY* in alt_keychars for all control keys. What about the English speaker who temporarily switches to the French layout and finds C-q mapped to C-a?) ]] No, we shouldn't. People who use the French layout expect that pressing control with the key to the right of tab passes C-a to emacs; English speakers (more exactly, Qwerty users) who temporarily switch to the French layout encounter that issue in every other app too, and they normally remap the keyboard in software as soon as they can, or learn to live with Azerty. That applies for all the Roman-alphabet keyboard layouts. Aidan Kehoe, 2005-05-15 I've taken out the dependency on MULE for this feature because it's also useful in a non-Mule XEmacs where the user has set their font to something ending in iso8859-5. How many of those users there are, is another question. */ Ichar alt_keychars[KEYCHAR_LAST]; }; the first level of indenting in the comments is from me; stuff i wrote back in 2001 or so. the second level is from aidan. what i wrote is heavily based on microsoft's ui style guide, as they have a long discussion of this issue. note also that this algorithm *does* use the locale of the current buffer; this is certainly possible under windows, where there is an explicit api to query both the physical and logical keyboard. it also seems that alphabetic and non-alphabetic keys should (perhaps) behave differently. now, from personal experience: i have had many times when i've been in foreign countries and had to log on to the internet. typically, the punctuation is in a completely different place. i always switched to us layout, and found it nearly impossible to use any other layouts. i *definitely* would expect in such a case that keyboard shortcuts involving punctuation should follow the logical, not physical, layout -- but with the physical layout as a backup, so when i temporarily switch to russian, i can still type C-x. (with alphabetic keys, it is semi-feasible to search the keyboard in front of me to find the keys, but this is just impossible for punctuation.) ben Paul Pogonyshev wrote:

Ben Wing wrote: I fail to see while it is impossible for punctuation, but here is my reasoning. (I'm constantly referring to Russian layout since that's what I use; I agree I'm somewhat biased because of this, since Russian uses a different alphabet.) Let's say we have punctuation following the logical layout, while the alphabetical key bindings remain on physically the same keys. I won't stress the consistency objection here, just the practical consequences for a Russian layout users (must also apply to any layout with an alphabet with more than 26 letters.) According to your proposal, key binding for command `M-.' (find-tag) will be on logical `M-.' in Russian layout, physically corresponding to English `M-/'. Now, many variants of the Russian layout (including Emacs' `russian-computer') don't have any way to type in the slash except by using the keypad. So, the command `dabbrev-expand' (M-/) becomes unavailable in Russian layout: there is no way to type that logically. And if you type that as-in-English, it invokes `find-tag', according to your proposal. This is just one example. There are certainly more, involving such key combinations like `M-^', `M-$' (which I use quite often) and others. All these cannot be typed with Russian layout and their physical keys clash with placement of punctuation on the Russian layout. Physical correspondence with English layout (which, I think, is marked on all keyboards, may be wrong here) is something all layouts have in common. In all other aspects they have lots of differences, including the location of keys corresponding to punctuation characters. One not-yet-discussed possibility is to distinguish between layouts for latin alphabet-based languages and all the rest (Cyrillic, Greek, ...) Since I only regularly use Russian and English layouts, maybe someone using, say German or Swedish layouts, could comment on this. Paul

Ben Wing wrote: There must be a misunderstanding. I'd like the keys (with modifiers) work as if the current layout was English (US), no matter what the current layout is. Without modifiers, they would of course insert the corresponding character based on the current layout. Seems like we speak of the same thing in different words, or, alternatively, I misunderstood you this time :) In fact, the internal Emacs input methods do just what I described. I just checked that. As it was mentioned here, in German layout keys for `z' and `y' are swapped relatively to the English layout. So, the key labelled `z' on my keyboard would type `y' after `C-x RET C-\ german RET'. However, combination `C-z' would still invoke `iconify-or-deiconify-frame', not `yank'. That's what I mean by physical vs. logical. It may blurry with different alphabets, like Cyrillic. But with German it should be more understandable: the key labelled `z' remains at physically the same position no matter what layout I use. However, with German layout, the logical key `z' swaps with logical key `y'. So, to finally clarify my position: I want layouts switched with external methods (`xkb') work just like Emacs internal input methods with regard to key bindings. Paul

Removing emacs-devel, as I don't pretend to recommend what to do for GNU Emacs. Feel free to quote me if you want to recommend it, though. Aidan> The X11 side of things doesn’t. It just supplies Qwerty as Aidan> an alternative. Win32 locale support in general is much Aidan> superior, and providing the same level of functionality in Aidan> pure X11 is just impossible. There is no locale -> key Aidan> layout mapping available, for a start. Today, "pure X11" can probably be taken to include the XKBD extension. This should be capable of providing similar levels of support. I don't promise it, but XKBD support is probably something we should do anyway, so this is another reason to look at that. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.