Change:
this._updateFont(); this._updateTheme(); <ins> ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the // marker file to get deleted and then focus back to the integrated terminal. if (request.termProgram === 'vscode' && request.filesToWait) { whenDeleted(request.filesToWait.waitMarkerFilePath).then(() => this.focus()); } }); </ins> // Force another layout (first is setContainers) since config has changed this.layout(new Dimension(this._terminalContainer.offsetWidth, this._terminalContainer.offsetHeight)); return TPromise.as(void 0);

Discussion:
I'm using vscode for editing commit messages and merging: .gitconfig After editing the commit and closing the commit editing / merge tab is it possible focus back the integrated terminal? I had the same feature in my vim
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.561 --<!-- potentialduplicatescomment --
I'm not sure there is a nice way to do this, any ideas?
I am actually also hitting this quite often... not sure how to best fix this. We do have code in place to delete the , so we are aware of the editor closing that was triggered via a invocation. But bottom line is that we would need to know that the operation was triggered from the integrated terminal to begin with...
there's this: They may not be 100% reliable though as an external terminal could have been launched by the terminal (could check ). Maybe the off chance of one of those happening is worth forcing focus? Another way you could do this is track the PID it was launched from on the CLI/main size and see if it's a child process of the terminal. Seems like a lot of work for such a small thing, we also only track the terminal process tree on Windows currently.
it is a bit of a hack but the terminal could also listen to the editor closing and checking if the file closed was part of  and then just put focus back to the terminal if: the terminal is open the terminal just had focus (?)
it's not so easy to know that the terminal launched the code CLI, it may be down the track when we track the process tree more though. When an editor is closed that was launched via --wait, can we track the and and focus the terminal of the same renderer if they match?
to clarify what I mean - integrated terminal - terminal which is integrated to the editor for example from vscode terminal: git add . git commit -a <vscode opens commit message editorI'm editing a commit -I'm pressing save and close the tab Integrated terminal should be focused back I apologize accidentally pressed the wrong button
yeah but this has to happen from the terminal layer, cannot happen from the workbench to avoid layer breakage. Are you saying that these environment variables are passed to the instance of VS Code that is starting from the integrated terminal?

We would probably need to wire these in through lots of places on the main side to eventually reach the renderer.
when code is launched via the CLI it inherits the environment of the shell which contains these vars. Ok, let's go with listening to editor close and checking  as you suggest. That is definitely nicer than wiring the values through. The listening should probably be done in PRs welcome
Is it alright to watch for waitMarkerFile deletion, since workbench will delete the marker file to signal when editing is done? See . Also, see the proposed fix . Using my development build, I'm not able to force vscode to use its window for resolving merge conflicts. Instead a new window is opened. My git config is identical to what aliev posted above. Any suggestions?
try to use that should force to reuse the last active instance. I think there are some things missing from your change: only do this listening if the marker file was opened from the integrated terminal handle the opening of the marker file within the running instance, in that case the request will come in via  and the configuration object that you are using will not reflect that, I think it would need a new event or something similar that gets emitted when a marker file is opened in the running instance
I think this is not as straight forward for a pull request so I went ahead to implement this via I took your idea about watching for the marker file to get deleted, thanks for that
on to the next one :wink: