Community
Participate
Working Groups
0.4 M1 To drop down a list of available commands, you hit Ctrl+Shift+L in the editor, or Shift+? anywhere else. This is confusing and makes it difficult to remember (and this is the last key binding you want to forget). I think we should just make it Ctrl+Shift+L everywhere...
We have similar mismatches with open resource. Probably others. The question is whether we want to say that all keybindings have to use Ctrl/Alt modifier keys so that on editor pages they will work. Many web apps use unmodified bindings but as long as we say that the binding has to be the same in the editor as elsewhere, we can't use those. Other opinions?
*** Bug 366845 has been marked as a duplicate of this bug. ***
*** Bug 368864 has been marked as a duplicate of this bug. ***
I discovered the find files dialog by accident. I am so used to Eclipse keybindings that I inadvertently type CMD+Shift+R in the editor and it did exactly what I thought it would. I would not have known that 'T' in the navigator would do the same thing (borrowed from github?). It seems to me that there are two paradigms at work here: Eclipse style keybindings when inside an editor, and github style keybindings everywhere else. It seems to me that it is unwise to mix the two paradigms. 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). That being said, I'd still prefer sticking with Eclipse-style bindings everywhere. Since that is likely familiar to a large chunk of potential users.
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).
Good point about eclipse keybindings stealing from the browser. This is probably not a viable solution, then. Presumably then, using ESC would bring up the same help window as '?' does outside of the editor. It would also be nice to be able to click in the help dialog to invoke the command (as you can in Eclipse).
Another suggestion, comment on this issue. This is perhaps a bit out of scope of what is being discussed here and also a bigger piece of work, so maybe I could create a different bug to discuss it more. One of the biggest difficulties that I am finding with Orion is that the set of interactions with the IDE is essentially closed. In any given context, there are a small number of commands that you can execute. Things like browsing the filesystem in the navigator view is tedious and interacting with git is also limited. I compare this with cloud9 ide, which has also has a similar limited set of keyboard commands, but they also expose a command line where you can do things like open files, issue arbitrary git commands, and execute basic unix-like commands (ls, cd, rm, mkdir, etc). It would be nice if pressing ESC would bring orion into command mode where you can type out basic commands and see feedback in a console window. I'd also imagine some basic completion support and hovers providing simple documentation.
*** Bug 369596 has been marked as a duplicate of this bug. ***
Here's what I propose for 0.4. For the commands that we add keybindings for globally (editor and non-editor pages), we need: 1) the same keybinding for both (or close enough that it "just works" without thinking 2) don't collide with popular browser key sequences. I agree that an Esc + Key sequence might work best in the long run for the editor, but until we figure that out.... 1) Open Resource (which we call Find File Named...) Ctrl (Cmd) + Shift + F this is kind of cool because it jives with "find" Ctrl-F and as far as I can tell, doesn't conflict with anything else. Ctrl+Shift+R is browser reload so we can't use that. What I like about this is that F also stands for "favorites" in addition to "file" so it can be remembered as both 2) Key Assist / Keyboard Help Ctrl+L = location bar on most browsers, and on opera, ctrl+shift+L is "display links" and on Safari ctrl+alt+L is downloads. I think that "L" seems to be used on the browser for "links/locations" so in this case, using the eclipse binding doesn't seem to make sense. I like the existing "?" (which is really Shift+/) and on the editor, perhaps (ctrl+? which is really ctrl+shift+/). 3) Toggle Banner Ctrl+Shift+M seems to be working 4) Toggle outline Ctrl+O seems to work good for now? I'm using this link http://dmcritchie.mvps.org/firefox/keyboard.htm (thanks, Carolyn) to look for potential browser conflicts, but I will test in IE9, FF10, Chrome 16, Safari before closing.
cc'ing some others who I know care about keystrokes
(In reply to comment #9) > 2) Key Assist / Keyboard Help > Ctrl+L = location bar on most browsers, and on opera, ctrl+shift+L is "display > links" and on Safari ctrl+alt+L is downloads. I think that "L" seems to be > used on the browser for "links/locations" so in this case, using the eclipse > binding doesn't seem to make sense. > I like the existing "?" (which is really Shift+/) and on the editor, perhaps > (ctrl+? which is really ctrl+shift+/). we could even ensure that ctrl+shift+/ (ctrl+?) works on the non-editor pages. That way if you learn ctrl+shift+/ on the editor, it will still work on other pages, but if you learn "?" from web apps, it will work everywhere except the editor. Mark, do you know if ctrl+shift+/ is a widely used editor key in textmate, etc.? because the other thing we have to be careful of besides browser keystrokes is common editor keystrokes. I can do some research on this tomorrow as well, just thought Mark might know.
Interesting...CMD-Shift-/ opens the help menu on macs. I never knew that. But, it would be a shame to override that keybinding to bring up key-assist in editor mode. On the other hand, using Ctrl-Shift-/ feels non-standard (because of the Ctrl), but I think the key combo is free. It's tricky finding really good key bindings that meet all the criteria.
(In reply to comment #12) > Interesting...CMD-Shift-/ opens the help menu on macs. I never knew that. > But, it would be a shame to override that keybinding to bring up key-assist in > editor mode. On the other hand, using Ctrl-Shift-/ feels non-standard (because > of the Ctrl), but I think the key combo is free. > > It's tricky finding really good key bindings that meet all the criteria. thanks, Andrew. As I looked at this last night, I kept thinking, "I know I would've used Ctrl(Cmd)+Shift+/ in the editor originally if it had been free" but I couldn't remember the conflict. That's the one. So the idea now is we use Ctrl+Shift+/ in the editor, and special case the Mac to actually use Ctrl vs Cmd. I can't come up with a better idea, and given we may change to use some other plan in the editor, this seems like a good solution for RC2.
Just remembered we use Ctrl in the Mac for other cases where Cmd is taken. (bug 366542) so I'm okay with using Ctrl for mac/editor.
mark, can you review the fix? It's in a remote branch, origin/bug366445 It looks like more change than it is because I moved the declaration of the "open resource" key binding closer to the command. otherwise it's just new keystrokes and an isMac test. I tested on Win7 Chrome, FF and Mac Safari
(In reply to comment #15) > mark, can you review the fix? > It's in a remote branch, origin/bug366445 > > It looks like more change than it is because I moved the declaration of the > "open resource" key binding closer to the command. otherwise it's just new > keystrokes and an isMac test. > > I tested on Win7 Chrome, FF and Mac Safari +1 I much prefer Ctrl+Shift+F for find files. With Ctrl+Shift+R I'd often accidentally invoke Reload and nuke my whole page.
pushed fix. thanks, Mark.
(In reply to comment #9) > 2) Key Assist / Keyboard Help > Ctrl+L = location bar on most browsers, and on opera, ctrl+shift+L is "display > links" and on Safari ctrl+alt+L is downloads. I think that "L" seems to be > used on the browser for "links/locations" so in this case, using the eclipse > binding doesn't seem to make sense. > I like the existing "?" (which is really Shift+/) and on the editor, perhaps > (ctrl+? which is really ctrl+shift+/). I noticed today that Google Docs uses Ctrl+/ for key assist. In Orion that is comment/uncomment, but at least it is close to your proposed Ctrl+Shift+/.
