Re: Key bindings proposal

[David De La Harpe Golden]

Apart from anything else, on x11, the windows keys are nowadays 
conventionally "Super", so x11 emacs already tends to see them as, well, 
"Super".


Xorg with a PC keyboard tends to map the windoze keys to the 
Super_L/Super_R modifiers.  x11 emacs therefore sees them as "Super" 
("s-" in emacs, as opposed to shift which is "S-").

(w32 emacs apparently calls them lwindow/rwindow and binds them to ignore)

X.org maps that menu key to the right of the right windows key to 
"Menu", which x11 emacs considers to be "menu", bound to 
execute-extended-command (i.e. M-x), at least if it gets to see it (i.e. 
window manager or whatever hasn't already eaten it).

(w32 emacs apparently calls it "apps" when it sees it and doesn't bind 
it to anything)

[On x11, I therefore put my window manager's various keybindings on 
Super (they're windows keys, heh), freeing up x11 Alt for emacs' Meta. 
Yes, I realise doing that on w32 is far harder than on x11.]


For completeness:

ns emacs encounters *step-type keys, apparently interpreting them (by 
default) as:

step-"Control" => emacs Control,
step-"Alternate" => Alt -> emacs Meta,
step-"Command" => emacs Super,
step-"Help" => emacs Hyper.

GNUstep/x11 itself can also be told which _x11_ keys to consider
which *step keys with the "defaults" tool e.g. you might do

NSGlobalDomain GSFirstControlKey Control_L
NSGlobalDomain GSFirstCommandKey Super_L
NSGlobalDomain GSFirstAlternateKey Alt_L
NSGlobalDomain GSSecondHelpKey Super_R
NSGlobalDomain GSSecondControlKey Control_R
etc.

(those are not the current out-of-box gnustep settings, they're choices 
that meant gnustep/x11 emacs' default mapping wound up close to x11 emacs)

On a real macosx keyboard, though, physically, compared to a PC:
"Control" tends to be similarly positioned to PC Control
"Command" roughly where a PC has Alt.
"Alternate" (well, "Option") roughly where a PC has windows keys.