Make explorer keybindings configurable
davidpmccormick opened this issue · 17 comments
Status
Please see #4557 (comment) for a list of available commands and contexts for explorer and opened editors view commands.
Original Description:
- VSCode Version: 0.10.11
- OS Version: Mac 10.11.3
When the explorer is in focus, hitting ctrl+enter will open the selected file to the side, but as far as I can tell, there isn't a keybinding to simply open the selected file (enter on its own will trigger renaming the file and ⌘+enter doesn't do anything).
Cmd+Down on Mac.
Is this configurable? And is it documented?
Not configurable at the moment, we took the same keybindings as the finder (https://support.apple.com/en-us/HT201236) for rename (= Enter) and open (= Cmd+Down).
I agree we should make this configurable though.
@jrieken does the new menu contribution story make it any easier to associate keybindings with actions? or is that a different concept that needs to be implement using the keybinding service and co?
I think both concepts are similar: You select an entry in the tree and set a context. Then you press a keybinding and expect one of the actions on this context to be invoked. All of those actions are likely also present in the context menu of that item.
It's like this:
- you can associate an
idto afunction(think offunctionasrunin an action) - you can associate a
keybindingto anid - you can associate a
menu itemto anid
Since the menu item story is just adding another UI gesture to invoke a command it's not making it easier or harder it's just a second way to invoke a command.
Today, there is a little debt as that we define the command (id -> function mapping) when defining a keybinding. We should extract a command registry and command service but using the existing stuff does everything you want - you can register a keybinding without keys - but stuff is a little clunky and we should add some convince functions.
Tho to truly adopt the keybinding/(future) menu item story these things need to be done
- implement the logic as command handlers (outside of an Action)
- add good context keys such that enablement/etc can be computed from the
whenclause - define default keybindings and menus
Update from VSCodeVim: This is now our most demanded feature.
@johnfn if you are referring to VSCodeVim/Vim#754 then I think we should create a new issue to track that because imho those keys apply to any tree we have in the workbench, not just the explorer. Imho it would be wrong to implement these keybindings on the level of the explorer, they should be supported on the level of our tree widget.
The goal of this issue is to make the explorer specific actions use configurable keybindings.
The following commands could already be assigned prior to 1.9 in the files explorer:
explorer.newFileexplorer.newFolder
The following commands of the explorer and open editors view will be configurable for keybindings in our 1.10 release:
Commands that work in both files explorer and opened editors view
explorer.openToSide: opening to the sideexplorer.copyPath: copy path of file/folderexplorer.revealInOS: reveal file in OS
Commands that only work in the files explorer
filesExplorer.copy: copy a file from the files explorerfilesExplorer.paste: paste a file that was copied from the files explorerfilesExplorer.rename: rename a file/folder in files explorerfilesExplorer.moveFileToTrash: move a file/folder to trash from files explorerfilesExplorer.deleteFile: bypass trash and delete a file/folder from files explorerfilesExplorer.findInFolder: find inside a folder from the files explorer
In addition to these commands, the following contexts are introduced for keybindings:
filesExplorerFocus: keyboard focus is inside the files exploreropenEditorsFocus: keyboard focus is inside the opened editors viewexplorerViewletFocus: keyboard focus is in either of the two
For example on macOS for changing the command to open from the explorer to be Enter:
{
"key": "enter",
"command": "list.select",
"when": "explorerViewletVisible && filesExplorerFocus"
}Looks good but why are those command ids to long? Wouldn't something like explorer.openToSide be sufficient and nicer than workbench.files.action.explorer.openToSide. I think workbench is like exposing an implementation/layering detail and action is strange because they are commands and that's already clear from the context, isn't it
@jrieken I agree and for all the newly introduced commands I can still make the switch to shorter commands, but harder for others that have been around for a while. We have a mix of workbench.action.files and workbench.files.action also from global actions. I wanted to keep them all related.
Would be cool if we had a way to deprecate command Ids to clean this up. I have a way to show a warning message whenever a command is triggered that no longer exists (see https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/browser/parts/editor/editorCommands.ts#L193) but it is a bit ugly because for that to work I still need to register the old command Ids and they will show up in the list of keybindings even though they are deprecated.
Pushed a change to shorten command Ids for the explorer. Worth mentioning that we have an insane mix of command ids ranging from using "action" or not, "workbench" or not, or no scope at all.
@jrieken I like that, but it would be better if we could hide such commands from the list of keybindings, otherwise I think it makes things more confusing for users trying to find the right command.
Yeah, needs a little extra info associated with it...