GNOME Bugzilla – Bug 395645
Metacity overrides Emacs hotkeys
Last modified: 2008-03-17 02:18:34 UTC
I know, "duh" from the title. Maybe we could have a way to detect Emacs windows and simply pass all keys on to them. Alt-Tab is the main problem.
(In reply to comment #0) > I know, "duh" from the title. :-) > Maybe we could have a way to detect Emacs windows and simply pass all keys on > to them. Alt-Tab is the main problem. I think this would be a really bad idea; users should either remap ispell-complete-word to a different keybinding in emacs or switch_windows to a different keybinding for metacity in gconf. Emacs and gnome-terminal is what I spend most of my time in and I alt-tab to/from emacs *all the time*; "magically"/"randomly" ignoring alt-tab keypresses (depending on the focused application) would annoy lots of users. Alt-space has always been the main problem for me with emacs & metacity, but I feel the same about it.
what Elijah said.
For completeness, here are the conflicting key bindings: Ctrl-Alt-D Metacity: Minimize all windows and give focus to the desktop. Emacs: * C-M-d: Moving by Parens. * C-M-d (Dired): Subdirectory Motion. Ctrl-Alt-L Metacity (GNOME Screensaver?): Lock screen Emacs: * C-M-l: Scrolling. * C-M-l (Rmail): Rmail Make Summary. * C-M-l (Shell mode): Shell Mode. Alt-TAB Metacity: Cycle through windows Emacs: * M-TAB: Symbol Completion. * M-TAB (customization buffer): Changing an Option. * M-TAB (Mail mode): Header Editing. * M-TAB (Picture mode): Tabs in Picture. * M-TAB (Text mode): Text Mode. Alt-SPC Metacity: Open window menu Emacs: Deletion
FWIW, I think there are many Emacs users in GNOME who are used to using Alt-TAB and Alt-SPC for their GNOME purpose who would be very bothered by a change. There are probably many fewer Emacs users who are put out by the GNOME bindings.
The way to think about hotkeys is that they are a small, finite number of global resources. The *only* way to avoid conflicts out of the box is to be absolutely consistent about what the hotkeys are (ideally, as with Windows, don't allow configuring them). If you keep changing hotkeys to try and avoid conflicts, every app chases every other app in circles, but if at least the desktop is consistent, the apps can over time work around it and arrive at a steady state. Of course, Emacs will never change for the post-twm age, at least not for another decade, but everyone will just have to live with that ;-) In the meantime, the fewer hotkey changes the better.
Yeah, neither Emacs nor the default bindings in Metacity should change. I wonder if it's possible to have a preference (yay!) to tell Metacity that for Emacs windows, it should only eat a hotkey if you press some magic key first. So Alt-SPC would be "just-one-space" in an Emacs window, but F12 Alt-SPC means "bring up the window menu" as usual in Metacity. [Yes, you then have to pick the magic prefix key, but hopefully that's easier...]
Just small note: : For completeness, here are the conflicting key bindings: : : Ctrl-Alt-D : : Metacity: Minimize all windows and give focus to the desktop. : Emacs: : * C-M-d: Moving by Parens. : * C-M-d (Dired): Subdirectory Motion. Please, pay attention that metacity uses Alt, while Emacs uses Meta. These modifiers are two different modifiers. And, therefore, there no conflict except cases when you assign both modifiers to the one and the same key (that is very rare because I forgot already when I saw keyboard without "windows" ket that can be used as "Meta"). Moreover, I'm as Emacs user would be disappointed if I would to lose WM keybindings inside Emacs and would be forced to use mouse without real need. Moreover #2: Even if for some reason you cannot to split Meta- and Alt- modifiers from the one and the same phisical key, you always can to re-bind anything what you need on your personal configuration (either Emacs, or Metacity or both) to resolve this conflict. Therefore, Please, do not reduce ability to use WM shortcuts in all cases just for handle one specific case.
What Andrew says about Alt and Meta not being the same thing is true. Recall also that Escape + X is the same as Meta-X in Emacs. I cordially dislike special cases. Since both Metacity and Emacs allow you to remap their bindings, I don't see that this should be a problem for most people. However, here's my suggestion. There will always be some application out there which wants an entire Wurlitzer keyboard all to itself: Emacs is an obvious example, but there might be any number of other applications. If you think there should be special arrangements made for such windows, as in comment 0, then we need to check for them; hardcoding a check for Emacs would be a bad thing. Therefore, the next step would be to go to the EWMH folks and ask them to make a _NET_WM_COKEBOTTLE window property, and then we can discuss over there how to implement it. :)