From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ben Wing Newsgroups: gmane.emacs.xemacs.beta,gmane.emacs.devel Subject: Re: thoughts on interaction of key bindings and input methods (was Re: wish: right alt/meta to switch keyboard layout while pressed) Date: Sat, 26 Nov 2005 19:48:16 -0600 Message-ID: <43891060.2070405@666.com> References: <200511222150.54248.pogonyshev@gmx.net> <200511261925.20191.pogonyshev@gmx.net> <17288.41589.506361.323637@parhasard.net> <200511270101.56195.pogonyshev@gmx.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1133056214 13425 80.91.229.2 (27 Nov 2005 01:50:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 27 Nov 2005 01:50:14 +0000 (UTC) Cc: Aidan Kehoe , XEmacs Beta , emacs-devel@gnu.org Original-X-From: xemacs-beta-bounces@xemacs.org Sun Nov 27 02:50:11 2005 Return-path: Original-Received: from gwyn.tux.org ([199.184.165.135]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EgBex-0004NH-RS for gexb-xemacs-beta@gmane.org; Sun, 27 Nov 2005 02:48:56 +0100 Original-Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id jAR1mcI0010288; Sat, 26 Nov 2005 20:48:45 -0500 Original-Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id jAR1mabm010282 for ; Sat, 26 Nov 2005 20:48:36 -0500 Original-Received: (from xemacweb@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id jAR1maY6010281 for xemacs-beta-mailman@xemacs.org; Sat, 26 Nov 2005 20:48:36 -0500 Original-Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id jAR1mZd6010268 for ; Sat, 26 Nov 2005 20:48:35 -0500 Original-Received: (from mailnull@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id jAR1mYog010267 for xemacweb@tux.org; Sat, 26 Nov 2005 20:48:34 -0500 Original-Received: from centrmmtao02.cox.net (centrmmtao02.cox.net [70.168.83.82]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id jAR1mTTm010243 for ; Sat, 26 Nov 2005 20:48:30 -0500 Original-Received: from [192.168.0.5] (really [68.0.175.25]) by centrmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051127014818.THLQ8484.centrmmtao02.cox.net@[192.168.0.5]>; Sat, 26 Nov 2005 20:48:18 -0500 User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en Original-To: Paul Pogonyshev In-Reply-To: <200511270101.56195.pogonyshev@gmx.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [0.0.0.0]); Sat, 26 Nov 2005 20:48:51 -0500 (EST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [0.0.0.0]); Sat, 26 Nov 2005 20:48:36 -0500 (EST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [0.0.0.0]); Sat, 26 Nov 2005 20:48:35 -0500 (EST) X-Greylist: Delayed for 37:03:15 by milter-greylist-1.6 (gwyn.tux.org [199.184.165.136]); Sat, 26 Nov 2005 20:48:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on gwyn.tux.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on gwyn.tux.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on gwyn.tux.org X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on gwyn.tux.org X-Virus-Status: Clean X-MIME-Autoconverted: from quoted-printable to 8bit by gwyn.tux.org id jAR1mTTm010243 X-XEmacs-List: beta X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gwyn.tux.org X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 X-BeenThere: xemacs-beta@xemacs.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: XEmacs Beta Testers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Original-Sender: xemacs-beta-bounces@xemacs.org Errors-To: xemacs-beta-bounces@xemacs.org X-MIME-Autoconverted: from 8bit to quoted-printable by gwyn.tux.org id jAR1mcI0010288 Xref: news.gmane.org gmane.emacs.xemacs.beta:21234 gmane.emacs.devel:46636 Archived-At: this is what i call the "russian c-x problem". at one point i had=20 worked out what the correct thing to do is, and there are various=20 comments to this effect in XEmacs; but i never finished it. it looks=20 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 i= t's also useful in a non-Mule XEmacs where the user has set their fo= nt 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=20 back in 2001 or so. the second level is from aidan. what i wrote is=20 heavily based on microsoft's ui style guide, as they have a long=20 discussion of this issue. note also that this algorithm *does* use the locale of the current=20 buffer; this is certainly possible under windows, where there is an=20 explicit api to query both the physical and logical keyboard. it also seems that alphabetic and non-alphabetic keys should (perhaps)=20 behave differently. now, from personal experience: i have had many times when i've been in=20 foreign countries and had to log on to the internet. typically, the=20 punctuation is in a completely different place. i always switched to us=20 layout, and found it nearly impossible to use any other layouts. i=20 *definitely* would expect in such a case that keyboard shortcuts=20 involving punctuation should follow the logical, not physical, layout --=20 but with the physical layout as a backup, so when i temporarily switch=20 to russian, i can still type C-x. (with alphabetic keys, it is=20 semi-feasible to search the keyboard in front of me to find the keys,=20 but this is just impossible for punctuation.) ben Paul Pogonyshev wrote: >Aidan Kehoe wrote: > =20 > >>[CCing XEmacs Beta, because despite it originating at emacs-devel@gnu.o= rg, >>this isn=E2=80=99t directly relevant to the FSF=E2=80=99s Emacs any mor= e, but there=E2=80=99s more >>value in keeping it visible than in keeping it in private mail.] >> =20 >> > >OK, I'll also CC it back to GNU Emacs' list for the same reason. > > =20 > >>[...] >> >=20 >> > Sorry, I'm on dial-up and I don't think I want to download megabytes= just >> > to test it. I use GNU Emacs normally. >> >>Sure. I hope you don=E2=80=99t mind if I ask you a few specific questio= ns then -- >> =20 >> > >Sure. > > =20 > >>-- If you see M-; listed as a key binding, is the first thing that occu= rs to >>you to type Alt+Shift+8? Or would you go for Alt+=D0=B6, since =D0=B6 i= s where ; is on >>the US keyboard? Should we accept both?=20 >> =20 >> > >I can't say which would be the most natural thing to hit, because few ap= ps >but Emacs use such extravagant shortcuts. > >Maybe I'd say like this: if an application uses _localized shortucts_ (i= .e. >is filled with things like `Ctrl-=D0=A9' and stuff), I'd go for `Alt-Shi= ft-8', else >`Alt-=D0=B6' i.e. `Alt-;' on English layout. Since Emacs is not localiz= ed in this >way (and cannot and mustn't be, I think), typing `M-=D0=B6' for `M-;' is= probably >more natural. > >Localized key bindings are impossible for Emacs, since you cannot type s= ay ']' >with the Russian keyboard layout. So, the only option is to type `C-]' = as >it is on English layout, which implies you must type all the other short= cuts >like this, for UI consistency and to avoid clashes. > > =20 > >>-- More generally, does this need to be done just for the alphabetic >>characters, or does punctuation need to be handled too? Looking at the >>Russian key layout, there=E2=80=99s no way to type `, ^, $, so I suspec= t you=E2=80=99re >>going to answer =E2=80=9Cyes=E2=80=9D to me on that.=20 >> =20 >> > >I cannot answer `yes' to an `or' question ;) Based on what I stated abo= ve, >I'd say that all shortcuts, in Emacs at least, must be invariant to phys= ical >keys, not to logical characters the keys produce with the current input >method/layout. > >This is probably also better ergonomically, since for power users (like = me ;) >key binding combos slip into subconsciousness. I don't think my interna= l >autopilot performs a ``hold the Meta key and type the semicolon, whereve= r it >is'' command, rather a ``press the key here with the left thumb, and ano= ther >one there with the third right finger.'' If it indeed works like that, >shortcuts staying at the same physical keys require less effort to memor= ize/ >push into subconsciousness. > > =20 > >>-- When I switch to the Russian layout in software, and type C-=D1=87 =D0= =B8 to call >>=E2=80=9Cswitch-to-buffer=E2=80=9D , I then need to switch the keyboard= layout back if I am >>to type *scratch*, which I frequently want to do. Is there a reasonable >>thing we can do there that doesn=E2=80=99t make it necessary to switch = layout?=20 >>Accepting =E2=80=9C;=D1=8B=D1=81=D0=BA=D1=84=D0=B5=D1=81=D1=80;=E2=80=9D= as an equivalent buffer name for =E2=80=9C*scratch*=E2=80=9D doesn=E2=80= =99t >>really seem like a great idea to me; maybe you _wanted_ to create a buf= fer >>with that name. I frequently create buffers named fdlsfdsfds and variat= ions >>on that, for example. >> =20 >> > >Accepting `;=D1=8B=D1=81=D0=BA=D1=84=D0=B5=D1=81=D1=80;' as `*scratch*' = won't work as a generic solution for >the reason you mentioned. It may be an optional heuristic, turned off b= y >default. There were some interesting programs for Windows that would >automagically switch the layout for you once you had started typing gibb= erish >in the current layout. I.e. if you typed ``Heccrbq'', it would consider= it >too weird an English word, backspace it and retype in Russian layout as >``=D0=A0=D1=83=D1=81=D1=81=D0=BA=D0=B8=D0=B9''. Likewise, it would auto= magically switch to English layout if >you typed ``=D1=89=D1=87=D0=BD=D1=8C=D1=89=D0=BA=D1=89=D1=82'' instead o= f ``oxymoron''. However, such heuristical >things often work incorrectly with artificial languages, like programmin= g >ones, and must never be forced on the user. > >The only plausible generic solution I can think of is to track the layou= t for >each buffer separately. This may be very difficult to impossible to >implement with external layout switching. And that's precisely the reas= on >why I prefer to use Emacs' own input methods switched by `C-\'. This me= ans >that I have to use different layout switching methods in Emacs and elsew= here, >but the advantages are more important for me. > >Another, less important, superiority of Emacs input methods for me is th= e >ability to easily activate an otherwise not used input method. I >occasionally activate Greek and German input methods. With Emacs it is >relatively simple, while with say KDE it would mean that I'd have to eit= her >constantly scroll through 4 layouts or go into the Conrol Center each ti= me >I need one of the rarely used layouts. > >Paul > > =20 >