After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 395645 - Metacity overrides Emacs hotkeys
Metacity overrides Emacs hotkeys
Status: RESOLVED NOTGNOME
Product: metacity
Classification: Other
Component: general
2.16.x
Other All
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-01-12 01:27 UTC by Federico Mena Quintero
Modified: 2008-03-17 02:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Federico Mena Quintero 2007-01-12 01:27:39 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.
Comment 1 Elijah Newren 2007-01-12 03:21:26 UTC
(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.
Comment 2 Thomas Thurman 2007-01-12 03:33:05 UTC
what Elijah said.
Comment 3 Dave Neary 2007-01-12 08:26:40 UTC
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
Comment 4 Dave Neary 2007-01-12 08:28:11 UTC
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.
Comment 5 Havoc Pennington 2007-01-12 16:10:38 UTC
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.
Comment 6 Federico Mena Quintero 2007-01-12 16:21:23 UTC
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...]
Comment 7 Andrew W. Nosenko 2007-11-05 08:53:41 UTC
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.
Comment 8 Thomas Thurman 2008-03-17 02:18:34 UTC
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. :)