Search does not respect `workbench.editor.revealIfOpen`

Selecting a search result will reveal an existing editor in an unfocused group even when workbench.editor.revealIfOpen is set to false.

Steps to Repro

• Set workbench.editor.revealIfOpen to false
• Open two editor groups
• Focus an editor in one of the groups
• Perform a search that will find results in the unfocused group (note that focus state is maintained while searching. The editor title color reflects this and workbench.action.focusActiveEditorGroup will focus the correct group).
• Select the result
• Notice it focuses the unfocused group instead of opening a new editor in the focused group

[akbyrd]

I don’t use that setting so I don’t really know what users expect

To add some user context here, I expected workbench.editor.revealIfOpen to be a global override that is respected almost everywhere. Definitely anything that feels like an intentional “open an editor here” operation should respect the option, imo. This would include clicking things in the explorer, clicking breakpoints, call stack, quick open, search results, and problems. I don’t have as strong of an opinion on go to definition, peek definition, and stepping in the debugger. I guess I lean toward them respecting the setting for consistency and predictability, but it’s not as strong of a preference.

My problem with revealing existing documents is that the focus move screws up my ability to organize editor groups. I typically have 2 groups open where each group is logically related. A common scenario is that one group is the code I’m writing and the other group is users of the code.

I frequently search for some symbol to look through all the locations it is used. I move focus to the right group before performing the search so that all results will open in that group. This leaves my ‘workspace’ alone (the left group when I’m actually editing) and let’s me mass close the right group when I’m done with it.

The problem is that in the middle of the search results for the symbol there are going to be entries for where the symbol is defined, which is usually where I’m editing. So I step through the results, editors are being opened in the right group, where I want them, I hit a result that reveals an already opened doc in the left group, and now all subsequent results open documents on the left.

[greggman]

Actually I take that back. While being able to drag to a window helps it still is a pretty poor UX. Trying to navigate unfamiliar code I have to manually keep track of which panes have which or else always use drag, never use click. That makes clicking a bad habit because you get used to using in and then, when you need it work with multiple panes you have to change to unfamilary behavior. Making clicking act this way is arguably a pretty bad UX.

I hope the VSCode team will consider revisiting this. Or tell us how and why the never run into this. I’d expect it to come up often on a large code base like VSCode itself.