96310 - Inconsistent use of Emacs keybindings

Status: VERIFIED DUPLICATE of bug 77976

(MailNews Core :: Composition, defect)

Description

[Jason Goodman]

This bug is related to bug 72352.

Ctrl-e, ctrl-a, ctrl-w, and a few other keys act like Emacs editing keys (go to
end-of-line, go to beginning-of-line, delete word) when a text box has focus,
but behave like menu shortcuts (edit page, select all, close window) everywhere
else.  This is a *good* feature.

BUT, other frequently-used Emacs keys, most notably ctrl-n, ctrl-p, ctrl-f,
ctrl-b (next line, previous line, forward one char, back one char) do not have
this behavior: they *always* behave like menu-bar shortcuts (new window, print,
find, bookmarks).

As a heavy Emacs user, I find this behavior unbelievably frustrating: I pop up
extra windows every time I try to move the cursor.  Having *no* Emacs keys would
be preferable to only a few -- the present inconsistent behavior puts my brain
in Emacs mode, and then breaks my expectations.

Netscape 4 supported the most common Emacs control-keys (n,f,b,p,a,e,k,d), and
I'd like Mozilla to do the same.  Since the different keymapping inside and
outside text boxes is a modal behavior which may confuse people (see bug 72352),
enabling these keys via a switch in the preferences is probably the best solution.

Comment 1

[Jason Goodman]

Hmm.  I just noticed that this bug happens ONLY in the Mail Compose window, and
not in textarea boxes in the browser.  I thought I noticed it happening
everywhere; either I was mistaken or the behavior is different between the two
machines on which I use mozilla.  I'll check this when I have access to my work
machine on Monday.

Comment 2

[sairuh (rarely reading bugmail)]

cc'ing linux-savvy editor folx.

Comment 3

[Akkana Peck]

This sounds like a dup of bug 77976. 

The basic problem is that Netscape's key bindings are designed by people who use
Windows, not the emacs/Unix bindings, and so there are lots of conflicting bindings.

The text control level bindings (emacs/Unix editing) are supposed to win over
the window-level bindings (Windows style) when there's a conflict, but a
regression in the key event handling code a long time ago broke that.
If you switch your accel key to be alt instead of ctrl (see
http://www.mozilla.org/unix/customizing.html) then you'll no longer have
conflicts and all the emacs bindings will work fine.  That's what I do and it's
my recommendation (in fact, I wanted to make it the default on Unix but lost the
war) unless you want to push for bug 77976 to be fixed.

If you have bindings which are NOT solved by using alt as the accel key, then we
may have forgotten a binding you consider important; if so, please comment here.

Comment 4

[Jason Goodman]

> This sounds like a dup of bug 77976. 

I suppose it is.  Different keys, same problem.

> The basic problem is that Netscape's key bindings are designed by people who use
> Windows, not the emacs/Unix bindings, and so there are lots of conflicting
bindings.

Understood.  I think it's more important for an app to be consistent with other
apps on the same computer than to be consistent across platforms, since people
use multiple apps on one system much more often than they use a single app on
multiple systems.  Unix keybinding standards are pretty weak (especially
compared to, say, MacOS) but they should be followed when they exist.

> The text control level bindings (emacs/Unix editing) are supposed to win over
> the window-level bindings (Windows style) when there's a conflict, but a
> regression in the key event handling code a long time ago broke that.

This is the bug which 77976 is supposed to fix, no?

> If you switch your accel key to be alt instead of ctrl (see
> http://www.mozilla.org/unix/customizing.html) then you'll no longer have
> conflicts and all the emacs bindings will work fine.

*THANKS*!  As a longtime NS4 / Emacs user, that pref gives a huge increase in
useability.  This would almost eliminate the need for this bug to be fixed, *IF*
the feature were well-documented and included in the GUI Prefs dialog box. 
Discovering the page you cited and mucking with the user.js file is too much to
ask a casual user.

> That's what I do and it's my recommendation (in fact, I wanted to make it the
default on Unix but > lost the war)

You're right: it should be the default.  See my comments on interplatform vs.
interapp consistency above.

> If you have bindings which are NOT solved by using alt as the accel key, then we
> may have forgotten a binding you consider important; if so, please comment here.

I've used Emacs for ten years, and I've *still* not learned to use many of its
alt-key commands.  So this solution is acceptable.  I'll agitate for 77976, and
post a RFE for including  ui.key.accelKey in the prefs dialog.

Comment 5

[André Dahlqvist]

So should this bug be duped against 77976, or should a dependency be added?

Comment 6

[Asa Dotzler [:asa]]

*** This bug has been marked as a duplicate of 77976 ***

Comment 7

[timeless]

vrfy dupe