After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 89587 - emacs-style bindings don't work in text fields
emacs-style bindings don't work in text fields
Status: RESOLVED DUPLICATE of bug 72245
Product: gtk+
Classification: Platform
Component: Widget: Other
2.0.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-08-01 06:58 UTC by Akkana Peck
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description Akkana Peck 2002-08-01 06:58:47 UTC
Some time ago, I found a document that used to live at
http://www.gtk.org/gtk-2.0.0-notes.html, which explained what to put in
~/.gtkrc-2.0 to make gtk2 behave like text fields on unix (and other OSes)
have historically behaved: in particular, 
gtk-key-theme-name = "Emacs"
gtk-entry-select-on-focus = 0
The emacs theme worked to enable ^A, ^E, ^K, ^U etc when I first found it,
but after upgrading to RH 7.3, gtk2-2.0.2, and gimp 1.3.7, they no longer
work.  

The latest gtk announcement, for gtk 1.0.5, still points to that same url,
but there's nothing at that address.

Has the filename or its syntax changed?  (I don't care if it's the default
or not, as long as I can get the behavior back.)  If so, perhaps the only
bug is that the url referred to in the release notes needs to be changed or
restored.

I looked for existing bugs covering this, but all I found was bug 46495 and
its dup, which seems to be nautilus-specific and ends inconclusively with a
suggestion to file a gtk bug report, but no pointer to the gtk bug which
was opened, if any.

I'm testing in gimp 1.3 from cvs, if that matters.
Comment 1 Akkana Peck 2002-08-01 21:39:35 UTC
Update: I upgraded to gtk2-2.0.5-5.  Now some of the bindings work
(^A, ^E, ^D) but the most important ones, ^H, ^U, and ^W, still don't
do anything.  Is there some separate config option I need to enable?
Comment 2 Akkana Peck 2002-08-01 22:18:35 UTC
Clahey kindly pointed me to /usr/share/themes/Emacs/gtk-2.0-key/gtkrc,
where I discovered the problem.  Replacing the existing ctrl-w line
with these three lines:

  bind "<ctrl>h" { "delete-from-cursor" (chars, -1) }
  bind "<ctrl>w" { "delete-from-cursor" (words, -1) }
  bind "<ctrl>u" { "delete-from-cursor" (paragraphs, -1) }

cured the problem, at least for text fields.

The ctrl-w binding that was there previously may be due to a
misunderstanding -- in emacs the editor, that's what ctrl-w does, but
in text fields and textareas, these three deletion keys have always
acted like they do in a shell.
Comment 3 Owen Taylor 2002-08-02 03:33:32 UTC
It's called the "Emacs" keytheme. Not the "combination
of emacs and terminal keybindings supported by GNU readline"... :)

 C-h in emacs gives help
 C-w in emacs is kill-region (sort of like cut)
 C-u is universal-argument - a little specialized

Resolving as a dup of bug 72245, since C-u is the only one
I'd really consider changing.




*** This bug has been marked as a duplicate of 72245 ***
Comment 4 Danielle Madeley 2002-11-08 08:33:07 UTC
These are better keybindings;
  bind "<ctrl>h" { "delete-from-cursor" (chars, -1) }
  bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) }
  bind "<ctrl>u" { "delete-from-cursor" (paragraphs, -1) }