GNOME Bugzilla – Bug 150059
Emacs keybindings not honoured for some operations (e.g. Select All)
Last modified: 2014-03-30 19:24:56 UTC
If a user has Emacs keybindings enabled for GTK, Ctrl-A is supposed to go the beginning of a line in a text box. However, gedit seems to have overridden this to mean Select All no matter what keybindings are selected. This is bad, and is not recommended by the GNOME HIG: The following emacs-style navigation shortcut keys are still available in GNOME 2.0 text entry fields (by selecting the "emacs" scheme in the GNOME Keyboard Shortcuts preferences dialog), but are disabled by default. Since some users will still want to use them, do not over-ride them for your own purposes in any situations where a text entry control has focus. Ctrl-A Move cursor to beginning of line
I think it is simpler and more straight forward for ordinary users to have Ctrl+A Select All. I am certain the HIG intended the goto start of line feature to work in single line text entry boxes, and I dont think it was ever intended to apply to the main document area of a program like gedit. While it might be good for users familiar with emacs to be able to override/disable the binding of "Select All Ctrl+A" I think it would hurt usability for most people to change the defaults to work differently from how they currently do.
Something very similar to this was discussed on the Gnome usability mailing list. http://mail.gnome.org/archives/usability/2004-October/msg00019.html My conclusion was that Emacs users are not normal :) (ordinary users, beginners that is) and that it is impossible to have the defaults be friendly for new users and still please Emacs users. The only viable solution would be to seperate out the Emacs keybindings into a seperate mode, where they can override whatever keybindings they want without making the defualts unsuitable for beginners. (By the way Abiword has an emacs mode that can be enabled by editing the file Abiword.Profile, asks the abiword lists if you wish to know more).
I don't understand how that isn't possible. Most other GTK+ apps respect GTK's preferences with regards to keybindings, instead of redefining Ctrl-A & friends to always be Select All.
abiword and gnumeric redefine Ctrl+A to be Select All on the main page area mozilla redefines Ctrl+A to be Select All on the main page area and only allows Ctrl+A to skip to the start of the line when in a text box. in gedit the main page is a text box widget if you were to steal the Ctrl+A to skip to the start of the line when would Ctrl+A work for Select All? For most users it would seem like the Ctrl+A shortcut for Select All did not work properly. it adds a lot of complexity to expect users to start figuring out about modes and to realise that the keybidings no longer work as expected because of a subtle difference in context. hope I have explained that adequately. (I cannot help wondering why if you like Emacs you would not use emacs or XEmacs or something else rather than gedit?)
This has nothing to do with liking Emacs, this has to do with the behavior that a large number of UNIX/Linux users are used to and which the large majority of UNIX/Linux applications still support. Why should I have to go looking for the Home key when ctrl-a accomplishes the same thing and keeps my fingers on the main part of the keyboard? Anyway, you're still missing my point. I'm not talking about stealing Ctrl+A, I'm talking about UNstealing it, to let the default GTK behavior be used, whether that happens to be the regular GNOME keybindings or the Emacs keybindings, whichever the user has set to be their default in GNOME/GTK.
I dont understand how you can have this keybinding in Gedit without effectively taking it away from Ctrl+A In other applications the textbox/textarea context is limited, but in Gedit you are virtually always in the text box so if you had Ctrl+A skipping to the start of the line Select All would seem to be broken. We are talking at cross purposes. I think the default GTK binding of Ctrl+A is unworkable and not a reasonable default for the average user, so I dont think it makes sense for it to work in the first place.
The default GTK 2.0 Ctrl-A binding _is_ Select All. It's only changed to the Emacs keybinding if you select Emacs keybindings.
Ok, I see Ari's point and I agree: IF the user has enabled emacs keybindings ctrl+a should not map to select all. If this is actually possible to do is yet to be seen. Patches are welcome :)
My apologies Ari, I had no idea that you had explicity make a choice to enable emacs bindigns. comment #7 makes it all clear.
Marking as AP4 to reflect accessibility impact.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
*** Bug 164410 has been marked as a duplicate of this bug. ***
Changing the summary for clarity: it doesn't affect only Select All.
*** Bug 168542 has been marked as a duplicate of this bug. ***
Bug 168542 was marked as a duplicate of this but it also includes Ctrl-n for next line, Ctrl-p for previous line, and Ctrl-f for backwards one character. In general, if the user goes through the trouble of configuring Emacs-style key bindings then the app should respect all of those bindings in a text widget. (I say it that way to try and prevent future new keybindings from stealing an Emacs-style key binding.)
Sorry, I meant Ctrl-f should be forward one character.
Carmine: yes we know that it affects many keybindings, as you can see the summary of this bug was changed to reflect that. Fact is, that I have really no idea if/how this is solvable: as far as I can see the problem is that we define those shortcuts harcoded in the menu (for istance "New <CTRL+n>) and the menu systems doesn't know anything about the TextWidget, it just intercepts the keybinding and activate the corresponding function.
Related: Bug #140378
this apparently works ok in 2.13.90 or later... at least jusding by the opposite complaint we got in bug 330609 :)
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
can anyone of you emacser check how thing goes in latest gedit? (2.16.2 and above)
I can confirm that Emacs keybindings still seem to work fine in gedit 2.22.1 documents, when the Emacs theme is selected. This does leave us with the long-standing problem that the shortcuts don't match reality when a non-default key theme is used, but that's a gtk+ problem, not a gedit one.
Created attachment 140183 [details] [review] Remove code set keybindings This is probably a silly patch because it's just commenting out a few lines that set keybindings in the code, but this seems to fix the problem for me. In Emacs mode ctrl+a goes to the start of the line and in Default it does select all. Also ctrl+k kills to the end of the line and ctrl+d deletes one char. It's really nice for us Mac textmate converts :)
Obviously the patch cannot be included upstream since that code is there for a reason :) A better way to fix it for your environment without patching the code is to change that shortcut in your gtkrc file (I am pretty sure it is possible, but I do not know the details though :)
No point keeping this 10 years old bug open. Better support for emacs-like keybindings will only happen if someone steps up to do the work at the Gtk level (GActions etc). It is pretty clear this will not happen at the gedit level