Closed
Bug 229473
Opened 21 years ago
Closed 19 years ago
emacs-like/readline-like ctrl+letter shortcuts should work on Mac OS X
Categories
(Core :: XBL, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.8.1alpha2
People
(Reporter: jtalkington, Assigned: jtalkington)
References
(Blocks 4 open bugs)
Details
(Keywords: verified1.8.1)
Attachments
(1 file, 1 obsolete file)
5.12 KB,
patch
|
neil
:
review+
sfraser_bugs
:
superreview+
cbeard
:
approval1.8b4-
neil
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
why only ctrl+k, and not the other emacs keybindings? (ctrl+u, ctrl+h, ctrl+a, ctrl+e, ctrl+w, etc)
Assignee: general → guifeatures
Component: Browser-General → XP Apps: GUI Features
Assignee | ||
Comment 3•21 years ago
|
||
Comment on attachment 138001 [details] [diff] [review] Adds control-k functionality for MacOS This actually causes control-<all> to kill to end of line.
Attachment #138001 -
Attachment is obsolete: true
Comment 4•21 years ago
|
||
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.
Assignee | ||
Updated•21 years ago
|
Summary: control-k should cmd_deleteToEndOfLine → control-blah combinations should work on MacOS
Assignee | ||
Comment 5•21 years ago
|
||
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.
Assignee | ||
Updated•21 years ago
|
Attachment #138013 -
Flags: review?
Assignee | ||
Comment 8•21 years ago
|
||
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•21 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•21 years ago
|
||
Comment on attachment 138013 [details] [diff] [review] Corrected patch. Neil, Simon, can you please take a look?
Attachment #138013 -
Flags: superreview?(sfraser)
Attachment #138013 -
Flags: review?(neil.parkwaycc.co.uk)
Attachment #138013 -
Flags: review?
Comment 11•21 years ago
|
||
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.
Attachment #138013 -
Flags: review?(neil.parkwaycc.co.uk) → review-
Assignee | ||
Comment 13•21 years ago
|
||
(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•21 years ago
|
||
(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•21 years ago
|
||
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.
Attachment #138013 -
Flags: review- → review+
Comment 16•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Updated•20 years ago
|
Summary: control-blah combinations should work on MacOS → emacs-like/readline-like ctrl+letter shortcuts should work on MacOS
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 22•20 years ago
|
||
Comment on attachment 138013 [details] [diff] [review] Corrected patch. moivng to neil
Attachment #138013 -
Flags: superreview?(sfraser_bugs) → superreview?(neil.parkwaycc.co.uk)
Updated•20 years ago
|
Component: XP Apps: GUI Features → XBL
Product: Mozilla Application Suite → Core
Comment 24•20 years ago
|
||
Comment on attachment 138013 [details] [diff] [review] Corrected patch. back to sfmr.
Attachment #138013 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview?(sfraser_bugs)
Updated•19 years ago
|
Attachment #138013 -
Flags: superreview?(sfraser_bugs) → superreview+
Updated•19 years ago
|
Summary: emacs-like/readline-like ctrl+letter shortcuts should work on MacOS → emacs-like/readline-like ctrl+letter shortcuts should work on Mac OS X
Updated•19 years ago
|
Assignee: guifeatures → jtalkington
Comment 25•19 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: blocking1.8b4?
Updated•19 years ago
|
Attachment #138013 -
Flags: approval1.8b4?
Comment 26•19 years ago
|
||
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.
Attachment #138013 -
Flags: approval1.8b4? → approval1.8b4-
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4-
Comment 28•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking-aviary2?
Comment 30•19 years ago
|
||
(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•19 years ago
|
||
(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 33•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
This is fixed in TRUNK builds. If you want the fix, download a trunk build.
Comment 36•19 years ago
|
||
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•19 years ago
|
||
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.
*** Bug 327607 has been marked as a duplicate of this bug. ***
Comment 40•19 years ago
|
||
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.
Attachment #138013 -
Flags: approval-branch-1.8.1?(aaronleventhal)
Updated•19 years ago
|
Attachment #138013 -
Flags: approval-branch-1.8.1?(aaronleventhal) → approval-branch-1.8.1?(neil)
Updated•19 years ago
|
Attachment #138013 -
Flags: approval-branch-1.8.1?(neil) → approval-branch-1.8.1+
Comment 42•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
> 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•19 years ago
|
||
(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•19 years ago
|
||
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
Keywords: fixed1.8.1
Updated•19 years ago
|
Target Milestone: --- → mozilla1.8.1alpha2
Comment 49•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
(In reply to comment #50) > That's because they aren't Cocoa text fields. > As alqahira@mindspring.com 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 54•18 years ago
|
||
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" → "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•18 years ago
|
||
(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•18 years ago
|
||
(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" → "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.)
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
Comment 57•18 years ago
|
||
(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•18 years ago
|
||
(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•18 years ago
|
||
The patch has nothing to do with DefaultKeyBinding.dict. It just adds the emacs shortcuts to platformHTMLBindings.xml.
Comment 60•18 years ago
|
||
(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•17 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•