-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
Expose a terminal API option to pause when the shell is exited #15583
Comments
We might have reached a point where it makes sense to talk about a second overload with an options bag. Like export function createTerminal(name?: string, shellPath?: string, shellArgs?: string[]): Terminal;
export function createTerminal(options: {name?: string; shellPath?: string; shellArgs?: string[]; waitOnExit?: boolean }): Terminal; |
Upstream issue to implement disableStdin (prereq) xtermjs/xterm.js#452 (PR xtermjs/xterm.js#453) |
Upstream PR is merged in |
This brings in disableStdio option (Part of #15583)
PR that exposes the new |
@dbaeumer FYI currently if a waitOnExit shell exits with a non-0 code I print the message that would normally go in the message box inside the terminal: |
No longer needed (yet), closing off. |
I hope we still have use for |
@jrieken the hope is still to move tasks to an extension, it's not the priority now though. A lot of the stuff that tasks need would be great for extensions to be able to hook into eventually as well, now we're just not rushed in pushing the APIs out. Some things that I can see us adding soon:
|
This is a requirement for the tasks framework to be moved to using the integrated terminal. The idea is to allow extensions to optionally specify they don't want the terminal to go away immediately after the shell process is exited but instead wait for input.
This would allow the tasks framework (and other extensions) to run a command that exits the shell immediately afterwards, and then wait for a keystroke or for the terminal to be killed manually, for example:
Proposed API:
/cc @jrieken @dbaeumer
The text was updated successfully, but these errors were encountered: