GNOME Bugzilla – Bug 330754
gnome-terminal should default to no mnemonics
Last modified: 2012-05-03 19:07:08 UTC
Just a thought, but gnome-terminal should default to no mnemonics since its very common to use bash as a shell and you have ncurses based apps that want to receive alt-key combinattions.
Or allow to bind these shortcuts to LWin-key instead of Alt-key.
*** Bug 331878 has been marked as a duplicate of this bug. ***
Sounds like a very good idea. F1 and F10 often conflict with console programs I use (like mp3blater or htop).
Perfectly agree. By the way, see bug 329827 which is a prerequisite for this one.
*** Bug 555799 has been marked as a duplicate of this bug. ***
All of these complaints boil down to the same thing: a terminal emulator should not take over in-band signals that logically belong to the terminal being emulated. Several of the current default shortcuts are standard ASCII or ANSI/VTxx/xterm input sequences. These should be reserved for the program's main business: emulating a terminal. As gnome-terminal(1) says: "Run any application that is designed to run on VT102, VT220, and xterm terminals." It should strive to provide this service as completely as possible. Traditional ASCII terminals transmit 7-bit ASCII characters. Terminal types built on top of this, like ANSI X3.64 and its common derivatives VT102 and xterm, assign certain combinations of these [generally ESC + stuff] to common keycaps like "F1". A terminal emulator should not take over any of the keycaps which are normal in-band input signals for the terminal type. Loosely speaking, this means it can't use any Shift+keycap or Ctrl+keycap combinations. Most emulators now support a `meta' mode where Alt+(normal char) sends (normal char) with its high bit set. Such emulators shouldn't take over Alt+ combinations. Modern emulators also support a "scancode" mode where the application can see the states of all Shift/Ctrl/Alt/etc. modifiers. When in that mode, most plausible sets of keyboard shortcuts are in-band signals and should not be used for shortcuts. But that is so drastic that it should be controlled by a user setting -- user can choose whether to block some in-band signals or not. The main sets of signals that _are_ available to an emulator (in non-scancode mode) are Ctrl+Shift+keycap and Ctrl+Alt+Shift+keycap. There are a few exceptions like Ctrl+Shift+6 == Ctrl-^, Ctrl+Shift+- == Ctrl-_, but mostly these are clear. (It helps that ASCII does not distinguish between Ctrl+letter and Ctrl+Shift+letter.) I've configured my Gnome-Terminal with a set of Ctrl-Shift shortcuts as follows: Edit Copy Shift+Ctrl+C Paste Shift+Ctrl+P File Close Tab Shift+Ctrl+W Close Window Disabled [too dangerous; use menu] New Profile Disabled [I use menu for this] New Tab Shift+Ctrl+T New Window Disabled [I use menu for this] Help Contents Shift+Ctrl+H Tabs Detach Tab Disabled [I use menu for this] Move Tab to the Left Shift+Ctrl+Page Up Move Tab to the Right Shift+Ctrl+Page Down Switch to Next Tab Shift+Ctrl+Right Switch to Previous Tab Shift+Ctrl+Left Switch to Tab [1..9] Alt+[1..9] Switch to Tab 10 Alt+0 Switch to Tab 11 Alt+- [next two keys right of Switch to Tab 12 Alt+= 1..9,0 on US keyboards] Terminal Reset Disabled [I use menu for this] Reset and Clear Disabled [I use menu for this] Set Title Disabled [I don't use] View Full Screen Shift+Ctrl+F11 Hide and Show menubar Shift+Ctrl+M Normal Size Shift+Ctrl+Insert Zoom In Shift+Ctrl+Home Zoom Out Shift+Ctrl+End So I disagree with the original premise of the bug reporter. Default shortcuts should not be abolished, merely changed to be out-of-band for all emulation modes where that's reasonably achievable.
Related bug: bug 413145
Fixed on master.