229473 - emacs-like/readline-like ctrl+letter shortcuts should work on Mac OS X

Status: VERIFIED FIXED

(Core :: XBL, defect)

Description

[Jerry Talkington]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031226 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031226 Firebird/0.7+

It's not well advertised, but MacOS X apps (including Safari) support the
*nix-ish control-k to kill to the end of line.  It's pretty trivial to implement.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jerry Talkington]

Attachment: Adds control-k functionality for MacOS

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

why only ctrl+k, and not the other emacs keybindings? (ctrl+u, ctrl+h, ctrl+a,
ctrl+e, ctrl+w, etc)

Comment 3

[Jerry Talkington]

Comment on attachment 138001 [details] [diff] [review]
Adds control-k functionality for MacOS

This actually causes control-<all> to kill to end of line.

Comment 4

[[e-mail]]

Comment on attachment 138001 [details] [diff] [review]
Adds control-k functionality for MacOS

There are at least two mistakes in this patch:
1. Tab characters.
2. Only VK keys have codes.

Comment 5

[Jerry Talkington]

Attachment: Corrected patch.

This enables the Emacsish key bindings on MacOS.  All of them are supported by
native Cocoa applications, with the exception of ^u and ^w, which don't have
any equivalents, but since most people who are aware of these bindings will be
expecting them, I included them.  It also includes ^v which pages down within
text  inputs.

Comment 6

[Torben]

*** Bug 207262 has been marked as a duplicate of this bug. ***

Comment 7

[R.K.Aa.]

*** Bug 237489 has been marked as a duplicate of this bug. ***

Comment 8

[Jerry Talkington]

Is there someone that the patch review should be assigned to?  I have a feeling
that it's not getting any attention due to the fact that it's not assigned, but
I'm not sure who should get it...

Comment 9

[Kathleen :Brade]

The bug should be assigned to the person who is developing the patch / fix.
The bug should be reviewed by appropriate persons (which is harder to determine).
Some possibilities include: Neil (who already looked at the patch once), me,
Conrad Carlen, Simon Fraser.

What I'm not completely clear on is if these keybindings change for different
languages / keyboard layouts / other.  I don't have the time to investigate that
particular issue right now (perhaps someone else can).  Probably it isn't an issue.

Comment 10

[Simon Paquet [:sipaq]]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

Neil, Simon, can you please take a look?

Comment 11

[[e-mail]]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

There appear to be two mistakes:
1. The input fields bindings should match the existing bindings i.e. ^N should
move to the beginning of the line.
2. The motion keys should be added to the browser binding.
Please note that I'm not in a position to test this patch.

Comment 12

[HARUNAGA Hirotoshi]

*** Bug 238068 has been marked as a duplicate of this bug. ***

Comment 13

[Jerry Talkington]

(In reply to comment #11)
> (From update of attachment 138013 [details] [diff] [review])
> There appear to be two mistakes:
> 1. The input fields bindings should match the existing bindings i.e. ^N should
> move to the beginning of the line.

Which existing bindings?  For MacOS apps, ^N means next-line.  IMHO, OS bindings
shoud override app bindings.

> 2. The motion keys should be added to the browser binding.
> Please note that I'm not in a position to test this patch.

I don't understand what you mean by motion keys.

Comment 14

[[e-mail]]

(In reply to comment #13)
>(In reply to comment #11)
>>(From update of attachment 138013 [details] [diff] [review])
>>1. The input fields bindings should match the existing bindings i.e. ^N
>>should move to the beginning of the line.
>Which existing bindings?  For MacOS apps, ^N means next-line.  IMHO, OS
>bindings should override app bindings.
Minor mistake: I meant it should move to the end of the line, like down arrow
does on input fields (which are single-line, in case it wasn't clear).

>>2. The motion keys should be added to the browser binding.
>I don't understand what you mean by motion keys.
You should be able to use all movement keys in caret browsing mode, and ^V
should always work, but you only defined it in inputs and editor.

Comment 15

[[e-mail]]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

OK, I've changed my mind on this, assuming that Ctrl+N and Ctrl+P keys do what
you expect in <input> controls.

Comment 16

[[e-mail]]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

>+      <handler event="keypress" key="v" modifiers="control" command="cmd_scrollPageDown"/>
Just out of interest, is there a scroll page up equivalent, perhaps
Option/Alt+V?

Comment 17

[Akkana Peck]

This is great.  I have mac users asking me how to enable these fairly often, and
it got a lot harder to describe since userHTMLBindings.xml stopped working.

(I wish we'd just make them cross platform.  Windows apps have traditionally
supported these bindings too.  But Windows moz developers don't seem to want them.)

Why are the up/down bindings (C-n, p, v) included for single line text fields? 
Is that intentional?

The Unix platformHTMLBindings.xml doesn't include ctrl-V for textareas or
editor, or c-w for editor, because of conflicts with close window and paste (and
because of bugs in the way that focus gets handled in XUL vs. XBL commands), but
for mac those are on cmd, so there's no conflict, right?

Adding browser actions to the motion keys when caret browsing sounds
interesting.  Are there xbl-accessible commands for all the needed cases?  That
should probably be a separate bug, anyway, and should apply to mac and unix
both.  (Please cc me if that bug ever gets filed.)

I don't know of a standard expectation outside emacs for [mod]-V for scrolling
up.  Within emacs it's meta-V, where the definition of "meta" varies with
keyboard and platform.  Do OS X textareas scroll up with any [mod]-V?

Comment 18

[Kathleen :Brade]

regarding the latest patch (attachment 138013 [details] [diff] [review]), has someone tested this on Mac
with accesskeys in the browser?  Which keybinding will win--accesskey or editor
shortcut key?  Or is this not an issue?

Akkana (comment 17) -- Typically up and down arrow cause the caret to move to
the beginning or end of the edit field.  I assume it's intentional to provide
that funcitonality with these keybindings but I'd probably find it easier to
just press the up/down arrow key.  :-)

Also, Paste and Close are Command-V and Command-W so those aren't a conflict.

Comment 19

[[e-mail]]

Inside an edit field the emacs shortcut key should win. Otherwise the general
access key will win as the patch didn't define browser access keys.

Comment 20

[HARUNAGA Hirotoshi]

*** Bug 247500 has been marked as a duplicate of this bug. ***

Comment 21

[Asaf Romano (gone)]

smfr?

Comment 22

[Asaf Romano (gone)]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

moivng to neil

Comment 23

[Asaf Romano (gone)]

*** Bug 275567 has been marked as a duplicate of this bug. ***

Comment 24

[Asaf Romano (gone)]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

back to sfmr.

Comment 25

[Asaf Romano (gone)]

fixed on trunk:
Checking in builtin/mac/platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/mac/platformHTMLBindings.xml,v  <-- 
platformHTMLBindings.xml
new revision: 1.17; previous revision: 1.16
done

Nominating for 1.8.

Comment 26

[Chris Beard]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

some question whether this should be in at all, let alone branch.  too late for
1.5.

Comment 27

[Wevah (Nate Weaver)]

*** Bug 301641 has been marked as a duplicate of this bug. ***

Comment 28

[Jochem Huhmann]

Why is this *still* totally broken in Firefox 1.5.RC2? After nearly two years? Even more broken actually, since there is no platformHTMLBindings.xml anymore, so you can't fix it manually anymore.

Comment 29

[Jesse Ruderman]

*** Bug 316007 has been marked as a duplicate of this bug. ***

Comment 30

[[e-mail]]

(In reply to comment #28)
>Even more broken actually, since there is no platformHTMLBindings.xml anymore,
>so you can't fix it manually anymore.
Actually you can, there's a pref somewhere to point at your own bindings.

Comment 31

[Jochem Huhmann]

(In reply to comment #30)
> (In reply to comment #28)
> >Even more broken actually, since there is no platformHTMLBindings.xml anymore,
> >so you can't fix it manually anymore.
> Actually you can, there's a pref somewhere to point at your own bindings.
> 

Hmm, where? Any documentation on that?

And yes, there's still platformHTMLBindings.xml in RC2, within toolkit.jar. I was in error with that...

Comment 32

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 319783 has been marked as a duplicate of this bug. ***

Comment 33

[Joanna]

I am using Moz 1.7.12 on a mac and I don't have emacs key bindings and there is no preference that gives them to me --- am I missing something?  It's also not mentioned in help...

Comment 34

[Dan Roca]

I am also not seeing this fixed in the latest releases of either Mozilla or Firefox. How can this be resolved fixed when there is no way for a consumer to actually get the fix?

Comment 35

[Simon Fraser [no longer active]]

This is fixed in TRUNK builds. If you want the fix, download a trunk build.

Comment 36

[waverider]

Camino1.0b2 release note say that emacs-like shortcuts can use.
If the improvement don't apply 1.0 branch, We should delete this description from 1.0 release note to stop misunderstanding.

Comment 37

[Berteun Damman]

I don't want to necessarily open this bug for my small complaint, but maybe it's worthwhile considering, although it'll probably involve a lot of work. The keybindings in Mac OS Cocoa text-inputs are far from fixed. Apple explains this here: http://developer.apple.com/documentation/Cocoa/Conceptual/BasicEventHandling/Tasks/TextDefaultsAndBindings.html

As you might have guessed, that's what I did… I've found a Trunk build, and although things like ctrl+h and such are working, they're working the way they work by default, any user-defined bindings or rebindings are completely ignored.

Comment 38

[Chris Lawson (gone)]

*** Bug 327232 has been marked as a duplicate of this bug. ***

Comment 39

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 327607 has been marked as a duplicate of this bug. ***

Comment 40

[Samuel Sidler (old account; do not CC)]

Comment on attachment 138013 [details] [diff] [review]
Corrected patch.

Requesting branch1.8.1 from aaronlev as he's the module owner for this.

This patch fixes the emacs-style commands on OS X and only affects Mac users.

Comment 41

[Samuel Sidler (old account; do not CC)]

Mano: Care to check this in on the 1.8 branch?

Comment 42

[Joanna]

Hi -- I am still waiting for a release (rather than the trunk build, though I did look up what that meant & add a wikipedia page on what that meant) but I just wanted to clarify something that judging by the comments may have got lost since many bugs have been folded into this one.

On linux, there is (or used to be) a check-box option to let you use emacs key bindings which just overrides whatever other key options you have set for other applications.  All most of us want is for this to be an option on ALL versions of Mozilla, not just linux. But especially on versions that are on unix platforms, like OS X.  I don't see any reason to confuse users who don't know they want emacs bindings.

Comment 43

[Rahul Abrol]

(In reply to comment #19)
> Inside an edit field the emacs shortcut key should win. Otherwise the general
> access key will win as the patch didn't define browser access keys.

the accesskeys always win, even inside text fields (as of 6 march 2006 trunk).

bug 128452 offers a number of solutions, but the only fix implemented so far seems to be changing ui.key.generalAccessKey, and this doesn't really work on macs (see bug 300678).

Comment 44

[Dan Roca]

There are no access keys on mac that interfere with emacs controls. (No mac access key uses ctrl as its base)

When will we see this in a release?

Comment 45

[Wevah (Nate Weaver)]

(In reply to comment #44)
> There are no access keys on mac that interfere with emacs controls. (No mac
> access key uses ctrl as its base)
> 
> When will we see this in a release?

I think you're confusing Mac key equivalents with HTML access keys (via the 'accesskey' attribute). Browsers on the mac use control for HTML accesskeys for the very reason you mentioned, though: system key equivalents almost never use control.

Comment 46

[Dan Roca]

> I think you're confusing Mac key equivalents with HTML access keys

Ah. You are correct. I thought we were talking about system keys not HTML access keys.

In this case, shouldn't GUI platform standards override seldom used HTML attributes?

Comment 47

[Joanna]

(In reply to comment #46)

> 
> In this case, shouldn't GUI platform standards override seldom used HTML
> attributes?
> 

Whether or not they should do this in general, there should certainly be an OPTION to let them do so.  

Incidently, this isn't just one GUI -- emacs key bindings are standard or available on a *lot* of other platforms.  Including Safari!!!!

Comment 48

[Asaf Romano (gone)]

1.8 branch:
Checking in platformHTMLBindings.xml;
/cvsroot/mozilla/content/xbl/builtin/mac/platformHTMLBindings.xml,v  <--  platformHTMLBindings.xml
new revision: 1.16.16.1; previous revision: 1.16
done

Comment 49

[Steve Jacobs (irc: encro)]

Requesting reopening of this bug (or perhaps Bug 327232):
https://bugzilla.mozilla.org/show_bug.cgi?id=327232


Text Input fields in Camino don't support custom keybindings in ~/Library/KeyBindings/DefaultKeyBinding.dict
or
/Library/KeyBindings/DefaultKeyBinding.dict

examples:
BBEdit http://hcs.harvard.edu/~jrus/Site/KeyBindings/BBEdit%20Bindings.dict Windows http://hcs.harvard.edu/~jrus/Site/KeyBindings/Windows%20Bindings.dict

more keybinding examples: http://hcs.harvard.edu/~jrus/Site/Cocoa%20Text%20System.html

Comment 50

[Wevah (Nate Weaver)]

(In reply to comment #49)
> Text Input fields in Camino don't support custom keybindings in
> ~/Library/KeyBindings/DefaultKeyBinding.dict
> or
> /Library/KeyBindings/DefaultKeyBinding.dict

That's because they aren't Cocoa text fields.

Comment 51

[Steve Jacobs (irc: encro)]

(In reply to comment #50)
> That's because they aren't Cocoa text fields.
> 

As [e-mail] noted this is also listed as bug 282097 for Firefox/Mozilla (all gecko prodicts?). Even though the renderer is not using an NSTextField if we had some support for keybindings this would be a really nice enhancement.

Comment 52

[froodian (Ian Leue)]

*** Bug 342777 has been marked as a duplicate of this bug. ***

Comment 53

[froodian (Ian Leue)]

*** Bug 339390 has been marked as a duplicate of this bug. ***

Comment 54

[Jacob Rus]

Ok, so this seems to have been fixed, at least in Camino.  I'm not sure if it's generally applicable to other Mozilla apps, or not.  Bugs which seem to be related are Bug 72352 and Bug 282097, the latter of which should be marked as a dup and closed.  This comment should maybe go there instead… I don't know really.

Anyway, I'm not sure where in the code this is, but the Camino support still has a few limitations:

1.  The most important limitation is that multi-stroke bindings are subtly broken.  Right now, I can create a binding for "control-m, control-a" (⌃M⌃A) which inserts a ⌘ glyph (for how to do this, see Allan Odgaard's [explanation][1] of my method).  This works fine.  The problem is that the second stroke of the binding is also interpreted, and so the cursor hops to the beginning of the line, where the ⌘ glyph is then inserted.  The correct behavior (implemented in NSText widgets, TextMate text fields, WebKit text widgets, and other places) is to place the glyph at the current location, and not interpret control-a separately.

[1]: http://macromates.com/blog/archives/2006/07/10/multi-stroke-key-bindings/

2.  There's no support for some selectors, the most useful being "setMark:" and "swapWithMark:".  For information on how these work, see my [article][2] and [list of selectors][3].  This doesn't really make very much real-world difference, as almost no users use these selectors (except for those who've read my article ;) ), and even those who do, don't generally really need them--I made a cool example which turns "this" &#8594; "this></this>" when control-< is pressed.  But it was mostly to push the limits of the system.

[2]: http://hcs.harvard.edu/~jrus/site/cocoa-text.html
[3]: http://hcs.harvard.edu/~jrus/site/selectors.html

Great job in general on implementing the bindings.  Having support for custom bindings spontaneously pop up a few months ago in a Camino nightly really made my day!

-Jacob

Comment 55

[Jacob Rus]

(In reply to comment #54)

Oh, one more thing.  the "yank:" and "yankAndSelect:" bindings don't work.  They just make the alert noise at me (yay wild eep).  "yankAndSelect:" is described [here][1].

[1]: http://hcs.harvard.edu/~jrus/site/cocoa-text.html#text_system_defaults

Comment 56

[Samuel Sidler (old account; do not CC)]

(In reply to comment #54)
> Ok, so this seems to have been fixed, at least in Camino.  I'm not sure if it's
> generally applicable to other Mozilla apps, or not.  Bugs which seem to be
> related are Bug 72352 and Bug 282097, the latter of which should be marked as a
> dup and closed.  This comment should maybe go there instead… I don't know
> really.

Jacob, are you saying that SeaMonkey, Firefox, and Thunderbird now respect DefaultKeyBinding.dict?

> Anyway, I'm not sure where in the code this is, but the Camino support still
> has a few limitations:
> 
> 1.  The most important limitation is that multi-stroke bindings are subtly
> broken.  Right now, I can create a binding for "control-m, control-a"
> (⌃M⌃A) which inserts a ⌘ glyph (for how to do this, see Allan
> Odgaard's [explanation][1] of my method).  This works fine.  The problem is
> that the second stroke of the binding is also interpreted, and so the cursor
> hops to the beginning of the line, where the ⌘ glyph is then inserted. 
> The correct behavior (implemented in NSText widgets, TextMate text fields,
> WebKit text widgets, and other places) is to place the glyph at the current
> location, and not interpret control-a separately.
> 

Go ahead and file a new bug for this under Core::Widget:Cocoa or Core::XBL as I'm sure they'll need to be in one of those two places to be seen and fixed.

> 2.  There's no support for some selectors, the most useful being "setMark:" and
> "swapWithMark:".  For information on how these work, see my [article][2] and
> [list of selectors][3].  This doesn't really make very much real-world
> difference, as almost no users use these selectors (except for those who've
> read my article ;) ), and even those who do, don't generally really need
> them--I made a cool example which turns "this" &#8594; "this></this>" when
> control-< is pressed.  But it was mostly to push the limits of the system.
> 

You're welcome to file a bug on this as well, though it's less likely to be fixed any time soon as, as you say, there's very little real world application.


(In reply to comment #55)
> Oh, one more thing.  the "yank:" and "yankAndSelect:" bindings don't work. 
> They just make the alert noise at me (yay wild eep).  "yankAndSelect:" is
> described [here][1].

Again, you're welcome to file a bug on this, but be sure to note how prevalent these are as far as use goes. If they aren't used much, the bug(s) will probably just be "futured" until such a time as someone with an interest decides to fix it.

And... if you do plan on filing bugs, be sure to do a quick search first (though it might be hard to determine where to search...) and CC me when you file them. :)

(Also, based on testing a recent trunk build and branch build, marking this bug as verified.)

Comment 57

[Jacob Rus]

(In reply to comment #56)

> Jacob, are you saying that SeaMonkey, Firefox, and Thunderbird now respect
> DefaultKeyBinding.dict?

I just tested this in nightly builds of Firefox and Thunderbird, and apparently no, they don't respect DefaultKeyBinding.dict.  So it's only Camino that does this for now.  Should I file bugs about the implementation only against Camino, in that case, or still file bugs against XBL/Widget:Cocoa/Widget:Mac?

Comment 58

[Samuel Sidler (old account; do not CC)]

(In reply to comment #57)
> I just tested this in nightly builds of Firefox and Thunderbird, and apparently
> no, they don't respect DefaultKeyBinding.dict.  So it's only Camino that does
> this for now.  Should I file bugs about the implementation only against Camino,
> in that case, or still file bugs against XBL/Widget:Cocoa/Widget:Mac?

Go ahead and file them in one of those core components.

Comment 59

[Simon Fraser [no longer active]]

The patch has nothing to do with DefaultKeyBinding.dict. It just adds the emacs shortcuts to platformHTMLBindings.xml.

Comment 60

[Jacob Rus]

(In reply to comment #58)
> Go ahead and file them in one of those core components.

Ok, I filed bug 348271

(In reply to comment #59)
> The patch has nothing to do with DefaultKeyBinding.dict. It just adds the emacs
shortcuts to platformHTMLBindings.xml.

Yes, I realize this.  However, the DefaultKeyBinding.dict support in Camino doesn't seem to have any bugzilla bugs associated with it.

Comment 61

[Rahul Abrol]

(In reply to comment #16)
> >+      <handler event="keypress" key="v" modifiers="control" command="cmd_scrollPageDown"/>
> Just out of interest, is there a scroll page up equivalent, perhaps
> Option/Alt+V?

this works in firefox 3.0b2:
      <handler event="keydown" keycode="VK_V" modifiers="alt" command="cmd_scrollPageUp"/>

neither event="keypress" nor key="v" will work, though.  bug 308565 may be the problem.