F1 is the desktop wide way to get help.

Using the dialog brought up by going to Edit -> Keyboard Shortcuts, you can change the key that brings up help, or disable that shortcut completely.

Does that work for you?

I totally support this bug!  F1 for help in a terminal is really not useful.

The proposition is to change the default binding to something else or to default it to be unbound? F10 and F11 are also taken by default, btw: while hopefully no editor has a frequently used key near them, it'd be nice to do something consistent (One could add Shift to them as we do for cut/paste; note that Shift+F10 is take too)

If this is changed, the docs should be probably updated.

see comment #1, this has been configurable forever.

g-t has always had the same keybindings policy:
 - make the defaults match the desktop norm, with the exception of 
   adding "shift" to the "ctrl+" shortcuts
 - if you use an app that isn't coordinated with desktop norms, 
   either get it fixed or configure something in Edit->Keyboard Shortcuts
   in gnome-terminal

the only way to make keybindings work by default is *keep them predictable and the same* so conflicts evolve away as apps work around each other. If every app keeps changing then keybinding conflicts never die.

So that's why gnome has a set of standard keybindings and does not change them.
Apps (including terminal apps) need to avoid these standard keybindings.

F1 incidentally is also Help on Windows and KDE, I believe. Probably OS/2 and CDE also, I would not be surprised.

Mariano - *every* other possible key is going to be used by something, unless you get into ctrl+hyper+super+alt+punctuation, and even then Emacs is already using it. Really, the best thing to do with keybindings is leave them unchanged, especially when it's a longstanding multiplatform binding.

The way I avoid this issue is to swap the «escape» and «capslock» keys.

(In reply to comment #4)
> see comment #1, this has been configurable forever.
> 
> g-t has always had the same keybindings policy:
>  - make the defaults match the desktop norm, with the exception of 
>    adding "shift" to the "ctrl+" shortcuts
>  - if you use an app that isn't coordinated with desktop norms, 
>    either get it fixed or configure something in Edit->Keyboard Shortcuts
>    in gnome-terminal
> 
> the only way to make keybindings work by default is *keep them predictable and
> the same* so conflicts evolve away as apps work around each other. If every app
> keeps changing then keybinding conflicts never die.
> 
> So that's why gnome has a set of standard keybindings and does not change them.
> Apps (including terminal apps) need to avoid these standard keybindings.
> 
> F1 incidentally is also Help on Windows and KDE, I believe. Probably OS/2 and
> CDE also, I would not be surprised.


Havoc, all you say is perfectly correct, but missing the fact that a terminal emulator is a special kind of application.

Think a vnc client.  Would you bind F1 to help or pass it through?  Now that's not the perfect analogy as vnc clients have a mode to bind/release mouse/keyboard, but the situation is very similar: people run apps inside both.

But a terminal app can use *any* keybinding, not just F1. Function keys are one of the less-common keys for terminal apps to use, if anything.

If you want to argue the terminal should have *no* keybindings then that's a different argument.

If you went the vnc route you'd have to do what vmware does, that is, carefully train people to know about a magic escape key to "get out" in order to keyboard navigate the terminal menus.

But presumably if you went the vnc route wholeheartedly you'd also want to disable window manager shortcuts when the terminal was focused or something ;-)
I would say that it's overkill for a terminal, since most terminals just have bash in there. If someone happens to run "mc" or whatever, then they can configure the terminal not to conflict with the specific app they run.

While I'm a heavy vi user, I notice the F1 key problem more when I'm using other apps inside gnome terminal that use F1.  A terminal emulator should emulate a terminal, and F1 is a popular key in terminals.  I guess disabling help in gnome-terminal is the way to go.

Uhm, how do you disable a keyboard shortcut?  I see that some items in the keyboard shortcut preferences page have 'disabled' next to them, but I can't seem to make the help contents become 'disabled'.  

The gnome terminal manual help for shortcut keys says "The Shortcut Keys section of the dialog lists the shortcut keys that are defined for each menu item.  Note: Not all keys can be used as shortcut keys, such as Tab." and that's it.

(In reply to comment #10)
> Uhm, how do you disable a keyboard shortcut?  I see that some items in the
> keyboard shortcut preferences page have 'disabled' next to them, but I can't
> seem to make the help contents become 'disabled'.  


Hit 'Backspace' when you are changing the keyboard shurtcut: that will disable it.

> The gnome terminal manual help for shortcut keys says "The Shortcut Keys
> section of the dialog lists the shortcut keys that are defined for each menu
> item.  Note: Not all keys can be used as shortcut keys, such as Tab." and
> that's it.

It certainly could be more obvious!

Shouldn't this be finally closed?

I just want to add this is a problem to opensuse administrative tool (yast2) as well. See: https://bugzilla.novell.com/show_bug.cgi?id=547694

If you're a regular vim user, it makes more sense to be using C-[ to exit insert mode, which works quite well with ctrl:nocaps or ctrl:swapcaps. Jumping way off the home row goes against the whole spirit of using vim :P.

It makes sense for gnome-terminal to fit in with the gnome desktop as a design choice, there are other vte-based terminals with different goals. The binding can be disabled in preferences, so in my opinion this can be closed.

I'm a regular vim user, having used it (well, vi), since 1987.  It's not that I'm telling you that you're wrong, but I've gotten quite used to using the esc key, and I don't think I could retrain that habit even if I wanted to.  Various keyboards seem to think [ is a prime candidate for relocation if they're short on space, esc less so: having to think about where the key is does not speed things up.  :-)

As to whether F1 should or should not be remappable, we let users customize the heck out of their desktop already, why should this be any different?

In reviewing this bug, the problem isn't vi, or yast2, or any particular program; the problem is that remapping or disabling shortcuts on keys like F1 was hard to figure out.  If the procedure is now easy and documented, then this bug should be closed.  If not, then it should be made easy and documented, and then the bug should be closed.

Thanks

This has nothing per-se to do with vi. A VT100 only has four function keys. By stealing (p)f1, you're taking away one quarter of the function keys a truly portable terminal app may have. Someone who has been using a particular app, which requires pf1, for years, but who is new to Gnome, may end up so baffled that he ends up installing and using xterm just to get around this problem. (Yes, I'm speaking from experience here.)

In my opinion, this should *not* be mapped by default. Terminal is not something your casual user is going to use a lot, and for most people who do use it, it's going to just work, and for those who really do need help, well, by default, the menu, with the help option, is displayed.

I had to come to this bug report to find out that I *could* remap the key bindings and make gnome-terminal work like an *actual terminal emulator*! I still haven't figured out *how* to do that. This is not a wise UI choice.

With F1 mapped to help, gnome-terminal is *not* VT100-compatible!

To follow up to my last comment: if you're worried about UI consistency between terminal and other Gnome apps, consider this: cut and paste are *already* mapped to non-standard keys, because Ctrl-C and Ctrl-V are too important to command-line apps. Well, the same applies, even if it's to a *slightly* lesser degree, to F1 (aka pf1 to us old VT100 users). So shouting "*consistency*" is not a winning argument here against changing the default.

I just realized that gnome-terminal still catches F1 and F10 by default, rather than passing them through to the app running inside.

I totally agree with Behdad in comment 7: It's a special app just like a vnc client.

Even the Copy-Paste, Find, New window etc. shortcuts are different from other apps, so what's the big deal with making Help also have either a different one, or none at all by default?

Could we please change the default not to grab any keys that are so useful for apps running inside?

Or, speaking a bit for myself, my two free software hobby projects being vte/g-t and Midnight Commander (where function keys are used heavily), could we please make mc work seamlessly in g-t by default? :)

(I'm totally fine with F11 full screen, and reassigning either F1 or F10 to F12.)

@chpe?

I'm fine with removing all the non-modified default keybindings, even.

In the mean time I'm wondering: why is the "Enable the menu accelerator key (F10 by default)" handled specially?

Is this GNOME-wide "accelerator key" an existing thing? F10 doesn't do anyting for me. Maybe it needs gnome-shell or something non-Unity?

Does it make sense to keep it this way (disabled by default), or should we move it to Shortcuts next to all other shortcut keys (in which case gnome-terminal becomes more consistent with itself, although we lose the ability to automatically follow the GNOME-wide default, which probably nobody would want anyway)?

Yes, F10 is handled separately because it's a global GtkSetting. I think we can just flip the default for menu-accelerator-enabled to 'false' too.

A consideration in the past is that for accessibility, it had to be possible to get into the menus and prefs without using a mouse. (F10 focuses the menu bar and then you can get to everything.) This keybinding is especially important to make standard since you can't open the menus to see what the binding for "open menus" is.

(In most apps, Alt opens the menubar too, but Alt doesn't work in gnome-terminal.)

Way back in comment 4, Havoc said that the gnome standards are to "make the defaults match the desktop norm, with the exception of adding "shift" to the "ctrl+" shortcuts". But terminal's already violating that! PgUp/PgDn, Home, and End aren't ctrl+ keys, but their behavior is to pass through to the app instead of scrolling the terminal!

This is going to be confusing to the newbie who pastes in a grep command he found online, and then can't figure out why PgUp doesn't let him scroll through the output!

The way its working now is pretty much the worst of both worlds. It's not consistent, it's not compliant with any sorts of standards, and it's confusing to newbies and experienced users alike.

The accessibility issue that Havoc mentioned in comment 22 is a bigger deal, but surely it's possible to catch when someone *just* presses Alt, and use that to bring up the menu, while still allowing Alt+[key] to pass through to an app?

So, we have two conflicting requirements. One is a necessity for a tiny fraction of use cases and/or users, the other is the expected behavior for most of the users.

How important is it to make it discoverable how to open the menus without mouse? Would Shift+F10, Ctrl+F10, Alt+F10 or F12 be acceptable? (By the way, Alt+F10 opens the menu for me. Not sure if it's g-t, Gtk+, Unity or who else.)

What are the main use cases why someone is without a mouse? I can think of two. One is that the system hw or sw is broken (the mouse or touchpad broke, or something is misconfigured, maybe the device is simply disabled). In that case I don't think it's needed to enter g-t's menus in order to fix it, you probably wouldn't care about g-t's shortcuts, font size or palette colors at this point. The other is if the user is unable to use these kinds of devices due to some disability. In this case is it fair to expect that they can search the web for the answer if they really need to look around in g-t's menus?

Most keyboards have a "right click" button (between the right Alt and Ctrl). Some (how many? maybe all?) laptops that don't have it have it on Fn + right Ctrl or perhaps some other similar keycombo. Would it help if we added opening the global Prefs dialog from this menu?

(On a slightly related topic: I just disabled the touchpad by clicking on the corresponding box in System Settings, and had a freaking hard time figuring out how to re-enable it. Okay it's not the stock GNOME experience, you can blame Ubuntu's "System Settings" app (which is pretty much the GNOME Control Center, as far as I recall), or the Ambiance theme for not being clear which item is focused etc... Also I'm wondering where the good-old Ctrl+Shift+NumLock mouse emulation is gone these days...)

I understand the importance of accessibility, but really dislike if this badly influences the "normal" behavior... it should be available for those who need it, but not get in the way of those who don't and those who expect F10 to be an F10 to mc and friends... so not sure what to do in this case.

(In reply to Chris Waters from comment #23)

> but surely it's possible to catch when someone *just* presses Alt, and use
> that to bring up the menu, while still allowing Alt+[key] to pass through to
> an app?

Actually, Ubuntu's default Unity 7 desktop does (almost) this automatically, for any app, not just gnome-terminal. (It doesn't open the menus, but brings up a search bar where you can search within the app's menu entries and invoke them, just by using the keyboard.) Not sure about gnome-shell perhaps doing something similar as well.

The F1 keybinding has been disabled.