Community
Participate
Working Groups
I get confused with our key bindings sometimes and wonder if we can just have one consistent set of key bindings without a Global and Editor mode. e.g Do we really need to treat the editor / visual content special. If we have a visual content plugin could we do something like but an invisible floating div in front to get a chance at capturing the key events first?
Where are you seeing problems? I think we fixed them all in bug 366445...global commands use the same binding in the editor. We do have places where mac is different (Ctrl/Cmd vs Ctrl, or using Alt) so there are differences but it's not editor modes. For the most part now we use the same bindings in and outside the editor. The downside to this strategy is that we are forced to use ctrl/alt/shift/cmd qualifiers inside the editor, whereas outside the editor that is not necessary. So we get lots of browser conflicts. This is discussed in another bug where Andrew E. suggested using an "Esc+" key mode in the editor so that we'd have more freedom in picking key combinations. Can anyone find that reference?
(In reply to comment #1) > This is discussed in another bug where > Andrew E. suggested using an "Esc+" key mode in the editor so that we'd have > more freedom in picking key combinations. Can anyone find that reference? actually it was in bug 366445. Andrew Eisenberg: So, either we stick with Eclipse-style bindings or come up with a completely different scheme. For example, when not in an editor, use github commands, and when in the editor, all key commands must be preceded with ESC, before the appropriate github style command (and perhaps ESC could also bring up a list of active bindings). John Arthorne: I agree our current state is not great and this is good input. One problem we have hit with traditional Eclipse bindings is cases where they interfere with key bindings usually taken by the browser (Ctrl+Shift+T is the heavily used "reopen closed tab" on Firefox for example). We were experimenting with the GitHub 't' keybinding because we realized on pages with no editor to steal keystrokes we suddenly have a lot more key binding options open to us than we did in Eclipse. I have recently being using vi again and I agree the idea of an "escape" key before key bindings in the editor is a possible option (maybe all that would do is open a little slideout that takes focus so the next keypress is interpreted as a command rather than input for the editor). ------------ A downside of the Esc idea is that you couldn't use this binding on a tablet with no keyboard, but we have key binding problems in general there anyway. For example, see bug 354698. Whatever we do here, I think we should be thinking about tablets and how an Esc strategy might map conceptually to that solution.
adding our other "key conflict," "multistroke" etc. bugs as dependent on this one. We can use this bug to track the overall strategy. Changing name of bug because I think the solution might be to be *more* modal so that we can use the same bindings across the editor and the rest of the UI.
To be honest I logged this because was seeing a lot of duplication and just did a localStorage.clear and now the situation is better. I'm still seeing a little bit of duplication still for things like Undo/Redo in the Editor and it would be good to do a more thorough check (which I'll do and report back here in a moment). I also find it a little ironic that the "Show keys" binding is different for Editor and Global. Despite being a mostly happy vi user all my life I'm not really sure we want to go down the modal key binding command path without really thinking hard about it. It's powerful but I think the usability really suffers. On the other hand I wouldn't mind "escape" taking me to a command line where I can see the commands I'm doing. Not sure if you consider that modal (I don't) or even if this is the right bug to discuss this in.
copying this reference from another bug, useful when we look at various keybinding strategies: http://dmcritchie.mvps.org/firefox/keyboard.htm http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
Hmm... I'm really not doing what this bug describes and am just using this bug for a verification pass in 0.5RC3 but will re-assign to Susan and target for 1.0 after that.
moving to 1.0
Re comment 4: > "I also find it a little ironic that the "Show keys" binding is different for > Editor and Global." Me too. :) In general, keystrokes like X and SHIFT+X will not work for screen reader users. See the "Navigation Quick Keys for HTML" section of: http://www.freedomscientific.com/doccenter/archives/training/JAWSKeystrokes.htm Also, SHIFT+/ (aka "?") means "Move to previous clickable element". So Alt+Shift+/ would be a better choice for our global "Show keys". (this is also mentioned in point (1) of bug 405441). JAWS also uses SHIFT+. SHIFT+, and SHIFT+; so pretty much all characters, and their shifted form, are taken (although screen reader users are generally able to "escape" or "pass through" the next keystroke, it would not be ideal to force them to do this)... ... and bug 364998 mentions that we need to avoid browser key bindings ... and bug 394414 mentions all the dev tools keystrokes that must be avoided ... which (in addition to sifting through all of the platform/browser/dev tool/screen reader keybindings already taken and using the few available slots left) brings us back to the "multistroke" idea of bug 364998. Note that I like the idea of an "Esc+" prefix where needed, but I'm not 100% sure that "Esc+" will be universally usable because it is often used for leaving some mode or other. Note that this is a hard problem <g>. I don't think GMail's keybindings (including their multistroke ones like g+i to "go to inbox", etc) could possibly be compatible with a screen reader's keystrokes. This is probably why GMail makes you explicitly turn on their set of keybindings. I will try to get guidance on this from some accessibility folks.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
