Retain editor focus after Run In Terminal #3303
Conversation
How to use the Graphite Merge QueueAdd the label graphite-merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
| this.terminal.show(); | ||
| this.terminal.sendText(command); | ||
| if (activeEditor) { | ||
| setTimeout(() => { |
There was a problem hiding this comment.
Without a delay here it fails. I'm unsure what would be a better way.
|
Do you mind recording demo vids for before/after comparison? I ran this branch but the behaviour seems to be the same (focus moves and stays at terminal). |
|
Sure, here's how it is on the current release. Notice that the cursor in the terminal is a solid block after the test finishes since it has focus. main.movAnd here it is on the branch, where focus returns to the editor window: branch.mov |
|
This pull request is being marked as stale because there was no activity in the last 2 months |
vinistock
added
vscode
|
Just FYI: we're trying to collect feedback about dev's expectations related to this. This change makes the focus more consistent with other explorer actions, but run in terminal has been the most popular actions for a long time and no one has ever brought up that they would rather not focus on the terminal. That is to say, it's unclear if the majority of devs will prefer this over the current experience and we're trying to assess that. |
I discovered that you can trigger a Code Lens with a keybinding, which is useful for Run In Terminal.
But currently the focus stays with the terminal so you need to focus back to the editor after doing so. This PR changes it to switch back automatically.
This does impact the current flow. For example, if someone is used to triggering a breakpoint with
binding.b, they will now need to focus on the Terminal panel before doing anything. I expect the majority of uses for Run In Terminal are likely not doing that though, so overall it should be an improvement.(Note: There is another change needed after this for the keyboard functionality to fully work).