Make explorer keybindings configurable

[davidpmccormick]

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).

[bpasero]

Cmd+Down on Mac.

[davidpmccormick]

Is this configurable? And is it documented?

[bpasero]

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.

[bpasero]

@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.

[jrieken]

It's like this:

• you can associate an id to a function (think of function as run in an action)
• you can associate a keybinding to an id
• you can associate a menu item to an id

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 when clause
• define default keybindings and menus

[johnfn]

Update from VSCodeVim: This is now our most demanded feature.

[bpasero]

@johnfn this is on my list to look into next milestone.

[bpasero]

@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.

[bpasero]

Actually let me reopen #11517 for this purpose.

[bpasero]

The following commands could already be assigned prior to 1.9 in the files explorer:

• explorer.newFile
• explorer.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 side
• explorer.copyPath: copy path of file/folder
• explorer.revealInOS: reveal file in OS

Commands that only work in the files explorer

• filesExplorer.copy: copy a file from the files explorer
• filesExplorer.paste: paste a file that was copied from the files explorer
• filesExplorer.rename: rename a file/folder in files explorer
• filesExplorer.moveFileToTrash: move a file/folder to trash from files explorer
• filesExplorer.deleteFile: bypass trash and delete a file/folder from files explorer
• filesExplorer.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 explorer
• openEditorsFocus: keyboard focus is inside the opened editors view
• explorerViewletFocus: 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"
}

[jrieken]

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

[bpasero]

@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.

[bpasero]

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]

Yeah, I have done things like this in the past

[bpasero]

@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.

[jrieken]

Yeah, needs a little extra info associated with it...

[bpasero]

Small update: I got rid of the extra filesExplorer.open and openedEditors.open commands in favour of the more generic list.select command (from #11517). In the end turns out that I do not need those commands and now every tree/list has a consistent generic keybinding for opening.