Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect revealIfOpen setting when opening editors with Quick Open #134478

Conversation

mkcode
Copy link

@mkcode mkcode commented Oct 6, 2021

This PR fixes an issue where there is inconsistent behavior between opening file and editors when using Quick Open with respecting the workbench.editor.revealIfOpen setting.

Before this PR:

  • Using Quick Open to open a file does respect the workbench.editor.revealIfOpen setting.
  • Using Quick Open to open an editor ( 'edt' prefix ) does not respect the workbench.editor.revealIfOpen setting.

Code-2021-10-06 at 01 13 05

After this PR:

  • Using Quick Open to open a file does respect the workbench.editor.revealIfOpen setting.
  • Using Quick Open to open an editor ( 'edt' prefix ) does respect the workbench.editor.revealIfOpen setting

Code - OSS-2021-10-06 at 01 01 05

This PR is tangentially related to #94705 where there has been lots of discussion.

I made an alternative implementation which introduces a unique setting workbench.editor.alwaysOpenInActiveGroupFromQuickOpen here: 02d4d73 But IMO, it is more clean to use the existing setting to create consistent behavior in this case, rather than introducing a new more granular setting.

@bpasero
Copy link
Member

bpasero commented Oct 6, 2021

This is by design: the list of editors in quick pick should focus on the editor you pick in the right group picked. Consider this picker like editor tabs: if you click on an editor tab you would not expect another editor to open, irrespective of the reveal if opened setting.

@bpasero bpasero self-assigned this Oct 6, 2021
@bpasero bpasero added a11y-partner Accessibility issue that a parter team is depending on info-needed Issue requires more information from poster and removed a11y-partner Accessibility issue that a parter team is depending on labels Oct 6, 2021
@mkcode
Copy link
Author

mkcode commented Oct 6, 2021

@bpasero - Ok. It looks like this PR would change the default behavior of VSCode which I believe would be unacceptable. I would still very much like an opt-in setting to enable this behavior, which I created here: 02d4d73 Would you prefer me to add this commit to this PR or open a new one?

@mkcode
Copy link
Author

mkcode commented Oct 6, 2021

Closing this PR in favor of #134525

@mkcode mkcode closed this Oct 6, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Nov 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
info-needed Issue requires more information from poster
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants