No keyboard friendly way to open multiple files in the current editor group

[ramya-rao-a]

Testing #41473

• Use multi select to select a few files
• The context menu has option to Open to Side, but there is no way to open in the current editor group
• Pressing Enter without opening the context menu opens the last file in the selection

When "workbench.editor.enablePreview": false, I'd have expected pressing Enter to have opened all the selected files in the current editor group.
Single click or Enter on a file opens it, so shouldnt the multi-select follow the same?

We sure can drag the files to the current editor group, but thats not keyboard friendly

[isidorn]

I agree we could improve this experience. Assigning to february to investigate then.

[isidorn]

The issue is that the explorer is reacting on selection change events and opneing files then.
This is not proper. There should be a command cmd + down mac, enter on other platforms which selects and opens the files.
Not for endgame, will do it next week

[isidorn]

@bpasero fyi I have introduced explorer.open command which can now be keyboard custmoized and support multi select. However I had to leave the ugly listener on selection change just to be able to expand folder on enter and cmd + down
@joaomoreno should the tree have built in support to expand an element with children on enter and cmd+down. Currently 'cmd+up' seems to collapse it. Do you mind if I add this directly to the tree, so every user benefits I can remove my ugly listening on selection change

[bpasero]

@isidorn I am not sure that is a good idea, we have a generic list.select command (among other commands there) that is shared for any list/tree in the workbench so that you can once configure a keybinding for how to select something across any list/tree. This for example is heavily used by the VIM extension to provide a consistent experience.

We should not introduce new commands for the same thing for specific trees/lists, that will just make it very hard for users to get the proper behaviour on other trees/lists.

[isidorn]

@bpasero ok agree we should not fight with list.select. Does it make sense for the list.select to toggle expansion here

[bpasero]

@isidorn I am not sure I can follow, maybe we talk next week in person. I thought this was about being able to open multiple files with keyboard?

[isidorn]

@bpasero sorry about that I misunderstood you in the previous comment. Let's take a step back.

So a lot of people are depending on selection change to open a file in the explorer. So I could bring back the old behavior, and introduce a command only if multiple files are selected in the explorer. That way I would not break any behavior and you would be able to open multiple at once.

[bpasero]

So a lot of people are depending on selection change to open a file in the explorer.

I think that this is a consequence of the commands we introduced 2 years ago where we adopted every tree to open something on selection if possible. Previously we had ugly Controllers that opened on various keydown/mousedown cases and then we changed all that to follow the selection model.

I would take a step back and think about what the user would expect: if on Windows you hit Enter on 2 files selected in the windows explorer, both open. Same for macOS if you select 2 files and hit Cmd+ArrowDown, so I think the logical consequence is that list.select should do the same when there is a multi-selection. I think at the time I added this command it was simply not caring about multi-select because that did not exist at the time.

Maybe we should do a similar thing as with Lists where we have an explicit open method and add that to the tree + add support for multi-select.

[isidorn]

Ok. So first let me revert my commit.

This is a bit complex subject because in our list and tree we have both focus and selection (I personally never understood the benefit of that).
@bpasero I suggest to discuss this in the office to see if we can somehow improve list.select as you suggest, though as I mentioned I think we will hit a wall due to our focus / selection discrepency. Since the select command operetaes on what is focused, and we can not figure out if the selection should be expanded or not.

[bpasero]

@isidorn well focus is (or should) always just one and the item that currently has keyboard focus. Selection can be multiple depending on what the user does. I think the issue stems from the fact that we overload selection and open for the tree. Maybe we can first fix it for the List and then see if that is possible given it distinguishes selection from opening.

How is expand/collapse playing any role here? I would not expect a selection to change the expansion state of an item?

[Mellbourn]

For reasons that are not obvious to me, issue #43676 was folded into this.

I'd just like to make a reminder that even though the title of this issue is No keyboard friendly way to open multiple files in the current editor group, there is still the following problem: There is no keyboard friendly way to open A SINGLE FILE in the current editor group

IMHO, that problem is much more important. Opening multiple files is a corner case. Opening a single file is something I do multiple times per hour.

[isidorn]

@Mellbourn doesn't cmd + down solve your issue?
@bpasero let's discuss this over a beer tonight 🍻

[d-akara]

Mellbourn Totally agree. This is marked as a feature.
However, #43676 was a regression and should have received high priority

Nevermind. I see cmd + down does the same thing. Although doesn't seem intuitive IMHO, but I can use it.

[Mellbourn]

@isidorn Yes it does! Awesome!

I had not found that command. It wasn't obvious to me that "list.select" means "open selected file". Maybe this can be named more clearly?

Anyway, thanks for the solution!

[isidorn]

We are already in endgame, and from Thu I am on vacation -> pushing this to April

[isidorn]

Select multiple files and press space.
This now works.
Thanks @bpasero for pointing this out