GNOME Bugzilla – Bug 269404
Emacs key bindings
Last modified: 2010-10-13 03:21:09 UTC
Distribution: SuSE Linux 9.2 (i586) Package: Evolution Priority: Normal Version: GNOME2.6. 2.0.1 Gnome-Distributor: SUSE Synopsis: Emacs key bindings Bugzilla-Product: Evolution Bugzilla-Component: UI Bugzilla-Version: 2.0.1 Description: Please describe your feature request: What happed to the Emacs vs Microsoft key bindings that was in version 1.4? it seems to be dropped in the 2.0 series. I like my Emacs key bindings. Unknown reporter: charles.swenson@usu.edu, changed to bugbuddy-import@ximian.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
The gconf key name changed without being documented. Here's how to turn on Emacs key bindings in 2.0: gconftool-2 -s /GNOME/Documents/HTML_Editor/keybindings_theme -t string emacs
*** bug 233779 has been marked as a duplicate of this bug. ***
Replying here since the bug I previously commented on (33779) has been marked as a duplicate of this one. As my earlier comment said, the GTK+ key theme *has* been set to "emacs" via a gconftool-2 command such as the one you gave; the gtkhtml editor nonetheless ignores this setting and continues to use the non-standard Windows-style keybindings. Any and all help would be much appreciated: Evolution is extremely frustrating to use when the standard keybindings are not working.
gtkhtml editor respects the emacs xml file. I would like to know which are the key bindings that are not working for you. Attach your copy of GNOME_GtkHTML_Editor.xml and GNOME_GtkHTML_Editor-emacs.xml, if possible.
*** Bug 315950 has been marked as a duplicate of this bug. ***
Please see bug 315950 comment 1 for some insightful thoughts. Reopening due to duplicate. Setting Target Milestone. This really should be fixed finally...
This bug has gotten worse with GNOME 2.13 and Evo 2.5.4. I actually had Emacs keybindings working with the default GNOME and Evo in FC4, but now Evo insists on treating ctrl-P as "Print" instead of "go up one line". Since printing crashes Evo right now (see bug 326572), I have the worst of all possible worlds: not only does a key that I use all the time not do what I want, it immediately crashes the mailer entirely.
Actually, I found a workaround for my specific problem. There's a plugin called "Print Message" in evo 2.5.4. If I disable it, the composer window no longer has a File->Print menu item, and ctrl-P doesn't get stolen, and now moves up a line.
Emacs bindings in the composer stopped working for me when I recently moved to Evo 2.4.1 under GNOME 2.12 on a Ubuntu system. I managed to get them back by removing the gnome-spell package (which was at version 1.0.6-1build2). This seems to be a known problem with gnome-spell (you can find mailing list threads about it in Google), but I haven't found any bugzilla entry about it. Maybe someone more knowledgable could have a look.
*** Bug 234108 has been marked as a duplicate of this bug. ***
removing old target milestone.
Looking into this a bit further, the GtkBindingSet emacs_bindings in _GtkHTMLClass is getting clobbered by something when Evolution uses it for composing email. There appears about a 0.5 chance of Emacs key binding the first time you open a composer window, and no apparent chance of it working the second and subsequent times. After adding some debug trace statements in key_press_event() in gtkhtml.c, I found the following: - When the Emacs key bindings are working, the value of emacs_bindings is non-null and has the correct GtkBindingSet set_name, i.e. "gtkhtml-bindings-emacs" - When the Emacs key bindings are not working, the value of emacs_bindings is still non-null but set_name is null. In both cases, the set_name is correct when GtkHTMLClass is initialised in gtk_html_class_init() in gtkhtml.c. Does anyone have an idea what might be causing emacs_bindings to get clobbered? Is there some gobject or bonobo magic that should be preserving this, but is not? I'm using: evolution 2.10.1 gtkhtml 3.14.1 gconf key "/desktop/gnome/interface/gtk_key_theme" is set to "Emacs"
I'm using 2.22.3-1 in Debian testing a year and half later. Is it possible to get this fixed? I just tried evolution in place of Thunderbird, but this is a showstopper.
The composer UI was rewritten for 2.24 and the Emacs key bindings got dropped because they haven't worked for a long time anyway. But I'll take a second look at this.
I take that back. Emacs bindings seem to be working fine for me, but the gtk_key_theme must be exactly "Emacs". Not "emacs" or any other variant. Also, new in 2.24, if any of the menu accelerators get in the way you can now change them on the fly just like most other GNOME applications. But you must have "Editable menu shortcut keys" enabled in Appearance Preferences. Just mouse over a menu item and press the key you want, or "Delete" to clear it. (This only works for the composer window right now, but I'm hoping to get this working in the rest of Evolution for 2.28.) So, GtkHTML -is- honoring its emacs keybindings. Are there any specific keybindings that it's getting wrong?
When I played with it this afternoon, no emacs bindings worked at all. I just checked again tonight and found that basic emacs keys are working now. I would like to see the copy/paste mappings also work. I will keep on playing with it and see if the problem returns.
Ah, not it's not working at all here. I have "Emacs" set for gtk_key_theme and still get no Emacs key bindings in Evo's message composer: > mjg@tremelay:~$ gconftool-2 --get /desktop/gnome/interface/gtk_key_theme > Emacs libgtkhtml3.14-19 1:3.24.1.1-0ubuntu1 evolution 2.24.3-0ubuntu1
(In reply to comment #16) > When I played with it this afternoon, no emacs bindings worked at all. I just > checked again tonight and found that basic emacs keys are working now. I would > like to see the copy/paste mappings also work. > > I will keep on playing with it and see if the problem returns. > I just changed to 2.26 and emacs keybindings broke again. This is incredibly frustrating. Evolution 2.26.1.1 in Debian testing as of 5/12/2009 I verified that desktop/gnome/interface/gtk_key_theme is set to "Emacs" in gconf.
*** Bug 304306 has been marked as a duplicate of this bug. ***
*** Bug 596232 has been marked as a duplicate of this bug. ***
Evolution 2.28.0 OpenSUSE 11.2 GtkHTML 3.14 Setting in desktop/gnome/interface/gtk_key_theme is set to "Emacs" It seems like a few key combinations work, for example "control-B" to move backwards one character, but C-F brings up Find; C-p the printer dialog; C-a selects all the text. In OpenSUSE 11.0 I was able to edit some XML files that were part of GtkHTML and at least brute force it into using the Emacs keybindings, with the new GtkHTML this is no longer possible.
It seems like the problem is not GtkHTML, as running the "test-stress" program uses all of the Emacs keybindings that we have been complaining about. This seems like the host, in this case Evolution is capturing the events for its own use before GtkHTML has had a chance to process them.
Further information: Evolution's host for the message composer overwrites at least Control-n (for new message) and Control-p (for printing) regardless of the settings on the system.
More updates, for the sake of anyone that needs to fix this for themselves. The problem is that the editor *component* (as opposed to the editor *engine*) is hardcoding a bunch of values regardless of the Emacs setting and ends up overwriting the values from the engine. This happens in gtkhtml-3.28.0/components/editor in the gtkhtml-editor-actions.c file. Here the Control-a, Control-e are overwritten and take precedence over the Emacs keybinding handled one layer below. I do not have a patch as I just went on a rampage deleting code since I was going insane and my email queue was growing every minute.
No intention of supporting emacs key bindings in GtkHtml. We're moving to WebKit soon anyway.
*** Bug 259331 has been marked as a duplicate of this bug. ***