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 510847 - ^W should not close conversation tabs with the Emacs Gtk key theme
^W should not close conversation tabs with the Emacs Gtk key theme
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Chat
0.21.x
Other Linux
: Low minor
: ---
Assigned To: empathy-maint
empathy-maint
: 661868 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-01-20 17:21 UTC by Will Thompson
Modified: 2018-05-22 13:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Will Thompson 2008-01-20 17:21:20 UTC
I have /desktop/gnome/interface/gtk_key_theme set to Emacs, so that Ctrl-U deletes to the start of the line, Ctrl-K deletes to the end of the line, etc., just like at the shell and in irssi.  But, Empathy intercepts Ctrl-W, which should mean "delete one word to the left of the cursor", in conversation windows and closes the window.  This turns out to be really annoying when I'm talking in a MUC and keep parting and joining when I forget that ^W doesn't work properly.

This seems to be a problem in quite a few Gtk applications.  Maybe the toolkit should be figuring this out for us.  I'm not sure.

(I could work around this if Empathy's menu accelerators were modifiable, but they aren't.)
Comment 1 Guillaume Desmottes 2008-04-13 17:28:15 UTC
Some advice from a GTK+ guru would be good here.
Comment 2 Guillaume Desmottes 2009-08-28 13:01:53 UTC
So you say you have the same issue in few GTK+ app. For example does Epiphany handles that correctly or hitting Ctrl-W in a form closes the tab?

Is there a GNOME/GTK+ consensus about this case?
Comment 3 Will Thompson 2009-08-28 22:23:19 UTC
I stopped using this around a year ago, because I couldn't rely on it working rather than destroying my data. (Pretty much when I filed this bug, in fact!) And now I can't make it work at all.
Comment 4 Will Thompson 2009-09-07 13:07:49 UTC
Hey, it's started working again!

Epiphany and Firefox both do the right thing, both in form fields and in the address bar.

GEdit also respects it. It respects it somewhat too effectively, actually: Alt-F move forward a word (which is what it does in Emacs) rather than opening the File menu.

Evolution does the wrong thing, as do AbiWord and Devhelp.
Comment 5 Tobias Mueller 2010-01-31 16:50:55 UTC
Hm. Interesting Issue. I'm not really proficient to tell whether it's an GTK+ or an application issue. But anyway, I feel that opening separate bugs for each application will help to get the issues resolved. So Will, please open bugs for each application you'll find misbehaving.

As this issue does not exist anymore, I'm closing as OBSOLETE.
Comment 6 Will Thompson 2010-02-01 10:54:36 UTC
(In reply to comment #5)
> As this issue does not exist anymore, I'm closing as OBSOLETE.

I'm sorry, I wasn't clear. Empathy does still misbehave. Reopening.
Comment 7 Guillaume Desmottes 2012-01-17 10:33:15 UTC
*** Bug 661868 has been marked as a duplicate of this bug. ***
Comment 8 Bilal Shahid 2012-01-18 15:27:23 UTC
same bug in the downstream in ubuntu and empathy 3.3.3
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/912872
Comment 9 Alexandre Franke 2015-11-24 11:19:32 UTC
Is this still an issue? If so, can you please update the version field with the latest version you can test this with?
Comment 10 GNOME Infrastructure Team 2018-05-22 13:06:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/8.