Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] (Ctrl+W doesn't close empty tabs)

NEW
Unassigned

Status

()

18 years ago
5 years ago

People

(Reporter: maolson, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: se-radar)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
I'd like to be able to turn off emacs keybindings, and I think others might as
well.  Most obvious to me is <ctrl>w, which will no longer close a window when
focus is on a textfield.

Rather than editing the bindings files, I'm going to investigate using a pref to
control this behavior.  There has been mention that there are potential
performance problems here, so any proposed solution will need to have minimal
impact with or without the pref set.
(Reporter)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 1

18 years ago
*** Bug 75685 has been marked as a duplicate of this bug. ***

Comment 2

18 years ago
i would like to nominate to the owner or submitter of this bug to change the 
platform to All & the OS to all.  i am a mac & windows (& linux, too) user who 
prefers emacs key-bindings.  i think there are many emacs users out there on 
various platforms/OSes who would like this as a cross-platform preference.

a minor issue.
*** Bug 64828 has been marked as a duplicate of this bug. ***
*** Bug 87643 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
*** Bug 84755 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
*** Bug 84168 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
Right. There should not just be a way to turn them off, but to turn them
entirely on - for example, the resolution to bug 51570 was to make ctrl-W always
try to close the window, when in a mail compose window. This is dangerous
behavior for someone who is used to the emacs keybindings.

So, whatever else the pref does, it should make sure ctrl-W never means "close"
when emacs keybindings are on, and always means "close" when they are off.

Comment 8

17 years ago
*** Bug 114831 has been marked as a duplicate of this bug. ***

Comment 9

17 years ago
Just a note: the emacs bindings are XBL bindings (and therefore user settable,
but not changeable at runtime).  The window bindings are XUL bindings, and
therefore coded in the jar files and not overridable.  A solution to this bug
would require that someone write code that bridges the gulf between XUL and XBL
bindings, and, probably, enable XBL if not XUL bindings to be changed at runtime
(since prefs currently aren't read until after the bindings have already been read).

Alternately, doing away with XUL bindings altogether and using XBL would also
make this easier to solve (though the change-at-runtime thing would still be
required if the change is to use a pref rather than userChrome.xml).

I'd love to see it happen, but it's probably going to require some tricky
surgery deep within the key/event handling code.  Just so you know what you're
getting into.

It's all completely XP code, and it would be extra work to make it unix-only, so
I'm taking the liberty of changing platform to all; if the bug's owner doesn't
agree, please accept my apologies and change it back.
OS: Linux → All
Hardware: PC → All
*** Bug 115300 has been marked as a duplicate of this bug. ***
*** Bug 116781 has been marked as a duplicate of this bug. ***
*** Bug 118551 has been marked as a duplicate of this bug. ***
updating summary/status so that i can query on this more easily.
Summary: Make emacs textfield keybindings a pref → Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix]
Whiteboard: se-radar

Comment 14

17 years ago
*** Bug 118739 has been marked as a duplicate of this bug. ***
*** Bug 119696 has been marked as a duplicate of this bug. ***
*** Bug 142250 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
*** Bug 147072 has been marked as a duplicate of this bug. ***
*** Bug 149581 has been marked as a duplicate of this bug. ***

Comment 19

16 years ago
Created attachment 106432 [details]
Keybinding suggestions

With reference to comment #9:
As an emacs user I don't care whether I get emacs keybindings via
 an XBL, XUL, XWY, or XQREXE binding.  As things are now, I'm not
clever enough to get them under any system.  How about having a program
that displays all the possible things you do with keybindings.	This
could allow you to check that you like emacs, vi, openoffice, ... and
would then set up defaults for those.  But then the user could click on
on one of the items and hit a key combination that would be used for that
action.  When the user clicks on all done, the appropriate configuration
files are written and if necessary mozilla is shut down and restarted,
or to simplify life for the developers the program could just tell the
user to do this.  To one who is ignorant of the internals of what it would
take to implement this, it seems that it might be done without changes to
existing Mozilla code as this would just sit off on the side.

Comment 20

16 years ago
*** Bug 140119 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Summary: Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] → Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] (Ctrl+W doesn't close empty tabs)

Comment 21

16 years ago
*** Bug 196450 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
Emacs keybindings, specifically ctrl-a, ctrl-e and ctrl-k should be implemented
by default in OS X, as all native apple apps (including safari) are able to take
advantage of these key bindings.  i'm not positive of what other keybindings
they support.

Comment 23

16 years ago
Todd: Please file that as a separate bug and cc me.  If you can talk the mac UI
folks into it, I'll volunteer to attach a patch implementing it (that's the easy
part, getting consensus is the hard part) .  It's not part of this bug, however.

Comment 24

15 years ago
*** Bug 218889 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
*** Bug 203428 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
*** Bug 217316 has been marked as a duplicate of this bug. ***

Comment 27

15 years ago
*** Bug 216930 has been marked as a duplicate of this bug. ***

Comment 28

15 years ago
Bug 119696 has been marked as a duplicate of this bug.

Comment 29

15 years ago
*** Bug 222247 has been marked as a duplicate of this bug. ***
*** Bug 226355 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Blocks: 189615
(Reporter)

Updated

15 years ago
Assignee: maolson → aaronleventhal
Status: ASSIGNED → NEW
QA Contact: bugzilla

Updated

15 years ago
Keywords: helpwanted

Comment 31

15 years ago
*** Bug 221901 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
Proposal:
1. If Mozilla is running on top of Gnome (if we can detect that), follow the
Gnome emacs key binding pref that's already in Gnome.
2. Otherwise, keep the same behavior we have now.

Mozilla should try to fit into the environment it's running on. If the emacs
bindings are working on the rest of the desktop, Ctrl+A should go to the
beginning of a line. If the rest of the desktop is using Ctrl+A to select all,
Mozilla should do that. In my mind this is similar to the bug where we don't
follow the Mac OS X tab navigation prefs.

Issues: 
- Can we detect if Gnome is running in an efficient manner?
- Does KDE have a similar pref that we can use if it's running?

Comment 33

15 years ago
I've reached a little mini-consensus on IRC that we should always just look gtk
setting.

1. If "gtk-key-theme-name" is present in a Gnome rc file (pointed to by
GTK_RC_FILES), use Emacs bindings if set to "Emacs"
2. else otherwise follow current behavior (which is to use Emacs bindings)

Users of any environment can edit that setting, whether they use Gnome or not.

Objections or comments?

Comment 34

15 years ago
Brian Ryner mentioned that Mozilla can use the gtkrc interface instead of
looking for the file ourselves.

Comment 35

15 years ago
Then the emacs set could have some of the bindings that are currently turned
off, like ctrl-W for word erase in the editor window.  Hooray!

There's a key theme in .gtkrc-2.0.  Is there one in 1.x?  This might only be
feasible in gtk2 mozilla builds.  Checking the gtk2 pref and not a kde pref is
probably reasonable given that mozilla has always been a gtk app (if we ever get
a qt build, then that can be revisited).  Using the gtkrc interface rather than
reimplementing that code definitely sounds like a good idea, since then we don't
have to worry about things like gtkrc files including other files.  Is "Emacs"
the only gtk key theme which implements these bindings?  Of course, people who
use custom themes and don't name them "Emacs" will have no recourse for mozilla.
:-(  I suppose ideally we'd check the gtk key theme and also allow the user some
way to set those bindings within mozilla.

Be aware of bugs 164638 and 89524 (which I think are dups of each other?).  It
may or may not be possible to change XBL key bindings after startup (those bugs
apply to the accel key pref, not to the bindings themselves).

Comment 36

15 years ago
(In reply to comment #35)
> Then the emacs set could have some of the bindings that are currently turned
> off, like ctrl-W for word erase in the editor window.  Hooray!
Yes, it goes both ways. By having a separate platformHTMLBindings.xml for emacs
we can have a clean separation instead of playing a game where we try to support
both at the same time (and not playing it that well).
We'll need a volunteer to separate the current unix file into 2
platformHTMLBindings files. I envision it being in
mozilla/content/xbl/builtin/emacs (as opposed to mozilla/content/xbl/builtin/unix).

> There's a key theme in .gtkrc-2.0.  Is there one in 1.x?  
Yes, people on IRC saw this setting in 1.2 as well.

> This might only be feasible in gtk2 mozilla builds.
We'll have a pref as well. I would implement this via
nsILookAndFeel:GetMetric(). The widget/src/base/nsXPLookAndFeel.cpp file always
checks a pref as a fallback override mechanism for setting metrics. That's
checked first to see if the override pref is used. If it's not, the indivual
widget/src/[platform]/nsLookAndFeel.cpp on each platform uses an OS mechanism to
set the metric. So, we need to hack wherever in Mozilla we define the location
of the subdirectory for the currently used platformHTMLBindings.xml. It probably
will not be that easy if only one copy of platformHTMLBindings.xml is JAR'd up.
We'd have to ship both.

> Checking the gtk2 pref and not a kde pref is probably reasonable given that 
> mozilla has always been a gtk app (if we ever get a qt build, then that can be 
> revisited).  
Agreed, we use the gtk settings in other places.

> Is "Emacs" the only gtk key theme which implements these bindings?  
Don't know, but we should have a pref

> Of course, people who
> use custom themes and don't name them "Emacs" will have no recourse
They will through the pref.

> Be aware of bugs 164638 and 89524 (which I think are dups of each other?).  It
> may or may not be possible to change XBL key bindings after startup (those
bugs apply to the accel key pref, not to the bindings themselves).
Hmm, that actually might make the pref impractical since the pref is loaded
after the profile manager. I'm not sure -- anyway we can still use the gtk pref
at least on Unix/Linux. As long as we hack the code to use the right
platformHTMLBindings.xml I think we're probably okay.

I could definitely use help on this, otherwise people will have to wait a while.
I just want to get an agreeable plan in place.

Comment 37

15 years ago
> Proposal:
> 1. If Mozilla is running on top of Gnome (if we can detect that), follow the
> Gnome emacs key binding pref that's already in Gnome.
> 2. Otherwise, keep the same behavior we have now.

Hmm, I run Gnome from time to time, but have no idea what "the Gnome emacs key
binding" is.  You can run Gnome, and a lot of applications that aren't Gnome,
thus never see the Gnome key bindings.  Therefore, I think a pref in Mozilla
should not be clever like this.  It should be the same behaviour regardless of
what kind of desktop the user happens to be running.
There should at least be a choice 3:

3. Use Emacs keybindings, period.

Comment 38

15 years ago
(In reply to comment #37)
> You can run Gnome, and a lot of applications that aren't Gnome,
> thus never see the Gnome key bindings.
So your argument is: because other apps don't try to fit into the environment
they run on, why should Mozilla? In that case, why do we try to fit into the
environment at all? We can totally ignore the native system settings and
appearance. :)

> It should be the same behaviour regardless of
> what kind of desktop the user happens to be running.
You want emacs key bindings on Mac OS X and Windows? You want function keys for
operations on the Mac? You want Alt+F to bring up the File menu on a Mac? Maybe
we should have a universal file open dialog and ignore the native one.

> There should at least be a choice 3:
> 3. Use Emacs keybindings, period.
No thanks -- that will mess the keyboard users on Windows and Mac too now.

Comment 39

15 years ago
Gnome: I thought about mentioning in my previous comment that whether gnome is
running is completely irrelevant.  I don't run gnome, but I run lots of gtk2
apps which read ~/.gtk-2.0 and my gtk2 key theme.

On gtk1: It may be that gtk1 had keythemes, but they definitely weren't
necessary to have the readline/emacs key bindings, so most users who expect
those bindings won't specify them in a .gtkrc for gtk1.  Most users who care
about the bindings probably have them specified in .gtk-2.0 by now; the question
is, can we call gtkrc routines which will check for .gtk-2.0 even from a gtk1
mozilla build?

Thanks for the info about using nsILookAndFeel and therefore having a pref
fallback.  That sounds like an excellent approach.

However, can I suggest a slight tweak?  Is there any chance that the fallback
pref could specify a file (either filename to be found in the profile, or a
file: url) from which to load the bindings, then not only would that solve this
bug, but it would also fix the userHTMLBindings.xbl regression (users used to be
able to specify their own key bindings, but can't any more).  I haven't looked
at the XBL file loading code in a while, so I don't know whether this would be
any more difficult.

>> 3. Use Emacs keybindings, period.
> No thanks -- that will mess the keyboard users on Windows and Mac too now.

There's a bug with a reviewed patch which is going to add them to Mac very soon,
if it hasn't already gone in.  There aren't any conflicts on the mac since the
mac uses cmd- for its window-level xul bindings.

Native windows apps have always used most of these bindings too, but not that
many people on windows seem to care strongly enough to fight to get them
included in mozilla to make it act like native apps.

Comment 40

15 years ago
> > You can run Gnome, and a lot of applications that aren't Gnome,
> > thus never see the Gnome key bindings.
> So your argument is: because other apps don't try to fit into the environment
> they run on, why should Mozilla? In that case, why do we try to fit into the
> environment at all? We can totally ignore the native system settings and
> appearance. :)

Applications should not try to fit the environment, they should try to fit the
user.  My argument is:  Users running Gnome may not care much for the Gnome key
bindings.

> > It should be the same behaviour regardless of
> > what kind of desktop the user happens to be running.
> You want emacs key bindings on Mac OS X and Windows? You want function keys for
> operations on the Mac? You want Alt+F to bring up the File menu on a Mac? Maybe
> we should have a universal file open dialog and ignore the native one.

Well, I don't do Windows much, but of course I want consistent behaviour in
Mozilla across platforms.  Note that many Mac OSX applications already has Emacs
keybindings.  Mozilla does not conform to the environment there.  Actually there
is a bug about this, 229473.
I have nothing against Mozilla trying to implement the most crazy keybindings if
it so chooses, but this bug is about getting Emacs keybindings as a preference.
 Gnome keybindings are not Emacs key bindings.



> > There should at least be a choice 3:
> > 3. Use Emacs keybindings, period.
> No thanks -- that will mess the keyboard users on Windows and Mac too now.

Exactly what Mac users want, see 229473.  I don't know about Windows users.

Comment 41

14 years ago
*** Bug 254903 has been marked as a duplicate of this bug. ***

Comment 42

14 years ago
*** Bug 256584 has been marked as a duplicate of this bug. ***

Comment 43

14 years ago
Did the patch in bug 257405 fix this?

Comment 44

14 years ago
Well, this is fixed in Firefox 1.0 Preview Release, so it looks like that patch
did it, at least for Firefox.

Comment 45

14 years ago
I totally agree that mozilla should have the emacs bindings switch it has under
linux on *all* platforms, and that it should replace native bindings.  That's
what anyone who would switch that preference on wants. 
No longer blocks: 189615

Comment 46

13 years ago
*** Bug 314597 has been marked as a duplicate of this bug. ***

Comment 47

13 years ago
Please consider that on MacOS X Emacs-shortcuts *are* native. All Cocoa-apps support them out of the box and there is no overlap to other shortcuts because OS X uses the Command key for these.

Comment 48

13 years ago
*** Bug 88743 has been marked as a duplicate of this bug. ***

Comment 49

10 years ago
It is embarassing that I have had emacs keybindings for Microsft Word and Outlook for eons, but Firefox and Thunderbird do not.

Not only that, but I used to have it working to some extent using the technique outlined here:
 http://kb.mozillazine.org/Emacs_Keybindings_(Firefox)

But due to this bug #201011, it has been broken a very very long time and is no longer possible to "do it yourself".

See also: #85799
Comment 39 seems to be about Windows, and has nothing to do with this bug as filed (which was Linux-only).  Please don't hijack bugs.

Comment 51

10 years ago
Oops, sorry.  Would take it back if I could.  I was moving too fast with my attempt to federate the related issues.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
QA Contact: keyboard.navigation
You need to log in before you can comment on or make changes to this bug.