GNOME Bugzilla – Bug 241187
Emacs keybindings ...
Last modified: 2003-10-17 18:26:08 UTC
changing the Shortcuts _type setting in the capplet doesn't allow one to save the changes (sensitize the apply/ok buttons). It also seems to have no effect - my bindings are not emacs-like, but perhaps this is the toplevel stealing the keypress before the embedded widget gets it ? surely it's focused though - so that should be no problem & it should get the events first ?.
in gtk2 menu accelerators _allways_ get events before the focused widget does. There is virtually no way to make emacs keybindings work well.
Short of re-writing the accelerators in the UI XML ? Try this; but the accelerators can be associated with the verb (instead of thee menuitem), and thus it may be possible to merge in two fragments of XML for the verb section eg.: <cmd name="EditSelectAll" _label="_Select All" ... accel="*Control*A"/> vs. <cmd name="EditSelectAll" _label="_Select All" ... accel=""/> or whatever. Of course - that sucks cut and paste wise; I'd much prefer to use the <keybindings/> section, but that (currently) doesn't show up in the menuitem's accel things, and it seems that (foolishly) I let the GtkWindow try and handle the keybinding before I did the lookup there, so I guess that suffers the same problem of not getting the event.
But even if we do that the merged accels from other controls will happily override keybindings that have no menu item so for instance ctrl-w and will ctr-a fire the To: entry "select all" if the editor has removed the accel?
*** bug 242105 has been marked as a duplicate of this bug. ***
*** bug 241303 has been marked as a duplicate of this bug. ***
*** bug 242726 has been marked as a duplicate of this bug. ***
*** bug 242727 has been marked as a duplicate of this bug. ***
after thinking about it for a bit, if someone sends me a GNOME_GtkHTML_Editor.xml with emacs accels and promises to maintain it when the ui changes I'll make the editor load the right one based on gconf key. That should make it mostly work I think...
*** bug 243829 has been marked as a duplicate of this bug. ***
*** bug 243443 has been marked as a duplicate of this bug. ***
*** bug 244430 has been marked as a duplicate of this bug. ***
Created attachment 42514 [details] Modified XML that doesn't clobber XEmacs bindings
I attached a modified GNOME_GtkHTML_Editor.xml. Most of the Emacs stuff works (C-a, C-b, C-f, C-n, C-p, C-k) I haven't found an entry for C-w, which still tries to close the window. :-(
*** bug 244462 has been marked as a duplicate of this bug. ***
*** bug 244760 has been marked as a duplicate of this bug. ***
Larry: have you seen the patch?
*** bug 242155 has been marked as a duplicate of this bug. ***
Yeah I've seen it and I'm just waiting for some time to do the integration work. Until then anyone who wants the emacs keybindings to mostly work should replace the file that gtkhtml ships with the one that Alain attached, of course doing that will break the ms keybindings so beware.
Here is a comment on behalf of someone who couldn't add it himself: <dwmw2> as well as installing the xml file attached to this bug you may need to run: <dwmw2> gconftool-2 -s /desktop/gnome/interface/gtk_key_theme -t string Emacs
*** bug 245479 has been marked as a duplicate of this bug. ***
*** bug 246459 has been marked as a duplicate of this bug. ***
*** bug 246920 has been marked as a duplicate of this bug. ***
Ok I committed a quick hack to the composer to load the right binding set based on the gconf key. So in gtkhtml CVS emacs keybindings work better. I'll attach the patch here and see what ettore wants to do about 1.4 branch.
Created attachment 42877 [details] [review] hack to work better in emacs mode
Created attachment 42878 [details] the emacs bindings I accidentally left out of the above patch
*** bug 249778 has been marked as a duplicate of this bug. ***