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

Allow extensions to access all terminals via API #13267

Closed
Tyriar opened this issue Oct 5, 2016 · 19 comments · Fixed by #47678
Closed

Allow extensions to access all terminals via API #13267

Tyriar opened this issue Oct 5, 2016 · 19 comments · Fixed by #47678
Assignees
Labels
api feature-request Request for new features or functionality on-testplan terminal General terminal issues that don't fall under another label
Milestone

Comments

@Tyriar
Copy link
Member

Tyriar commented Oct 5, 2016

To give extensions more control over the terminal panel I'm proposing the following:

export namespace window {
  export const onDidOpenTerminal: Event<Terminal>;
  export let terminals: Terminal[];
}

A solid use case for this is to represent the terminals as tabs somewhere in the UI https://github.com/Tyriar/vscode-terminal-tabs

@Tyriar Tyriar added feature-request Request for new features or functionality api terminal General terminal issues that don't fall under another label labels Oct 5, 2016
@Tyriar Tyriar self-assigned this Oct 5, 2016
@Tyriar
Copy link
Member Author

Tyriar commented Oct 5, 2016

What do you think @jrieken?

@jrieken
Copy link
Member

jrieken commented Oct 6, 2016

Not yet sold on the importance and future-proof of that API. I would suggest to hold back with this API until the discussion about moving terminals into the editor space comes to an result (we recently talked about that in a UX sync). Then we might have a different set of requirements and limitations.

@Tyriar
Copy link
Member Author

Tyriar commented Oct 6, 2016

I was at one of those meetings that talked about that and it was shot down pretty hard, it would make management of terminals much more difficult and blur the lines between a panel and an editor. Would that really change the requirements though, this is just adding an open event and a list of terminals which would still be valid regardless of where a terminal was?

@jrieken
Copy link
Member

jrieken commented Oct 7, 2016

I am pretty sure the discussion will come again once we introduce horizontal editors. Not saying we merge panels and editors (errors, output, debug should stay there), but I have the (strong) feeling that terminal a much more like editors (I create/dispose them, I manage them) and for editors we have the far superior story for managing/navigating them. Like html-preview and extension-editors, terminal would greatly benefit from that IMO.

Taking about the API: It might not look any different but I just want to be careful and not rush into something we cannot change again. I don't see strong feature pressure for this so I would wait for the bigger workbench UX changes to land first.

@Tyriar
Copy link
Member Author

Tyriar commented Nov 16, 2016

This may be necessary to scan the output of a gulp watch (or similar) command on any terminal and using co-processes (#13337) to send errors to the problems panel. /cc @dbaeumer

@jrieken
Copy link
Member

jrieken commented Nov 17, 2016

Wouldn't activeTerminal and onDidChangeActiveTerminal APIs be better for spying on them?

@Tyriar
Copy link
Member Author

Tyriar commented Nov 17, 2016

@jrieken for the problems use case you would want to watch the output of terminals in the background. When working on VS Code for example I have 2 terminals; gulp watch (typically background) and ./scripts/*.sh (foreground).

@dbaeumer is this right? You would want to watch any terminal, not just ones that were launched via an extension?

@dbaeumer
Copy link
Member

I would like to watch the output of potential all terminals. However for the input I only need the active one. The user can only type in one terminal anyways.

@rkeithhill
Copy link

@jrieken For an example of how the current behavior is sub-optimal see PowerShell/vscode-powershell#604

We would love to see something like this for the PowerShell extension if it allowed us to bypass that initial, useless terminal startup. We now have an "integrated console" that effectively replaces the Debug Console at debug time and provides a REPL experience at edit time. That is, our integrated console allows the user to play around in the same PowerShell process that hosts both the language and debug services. This gives a nice SmallTalk-like REPL experience that spans edit & debug.

The only way to plumb this in was to add another terminal type - PowerShell Integrated Console. Unfortunately when VSCode first starts, it loads up the default terminal first before we get a chance to start our integrated console.
cc @daviwil

@daviwil
Copy link
Contributor

daviwil commented Apr 21, 2017

Any chance we could see what shell exe the terminal launched? I know it's a bit of a grey area, but might be nice for determining whether I should kill one of the terminals in favor of the PowerShell Integrated Console.

@Tyriar
Copy link
Member Author

Tyriar commented Apr 24, 2017

@daviwil the usage of it would probably be pretty limited, if you're just tracking the initial panel restore you could probably get around it some other way. I'm extra hesitant to add since it could be misleading, say if someone opens cmd inside powershell.

@daviwil
Copy link
Contributor

daviwil commented Apr 24, 2017

Sounds good, I definitely understand not wanting to add something of limited value!

@cvgaviao
Copy link

Hi, I'm facing a situation where I 'll need to create one terminal for every root folder (selected project) because the commands I'm registering need to run in its own root folder terminal. But I would like to create the terminal only once, but don't know how to retrieve an already created one.
any tip?

@handletastic
Copy link

Has there been any updates as off 2018?

@Tyriar
Copy link
Member Author

Tyriar commented Feb 27, 2018

@hdsantos89 nothing other than more interest in getting at the PID of all terminals in #42521

@Tyriar
Copy link
Member Author

Tyriar commented Mar 9, 2018

To give a summary of the needs for this API:

Let me know if I missed anything

@fabiospampinato
Copy link
Contributor

fabiospampinato commented Mar 9, 2018

their kill command currently runs workbench.action.terminal.kill 25 times

Exactly, other than being pretty ugly and most of the times inefficient there are no guarantees this will even work (maybe the user has 26+ terminals open for some reason).

A few more things that could be done with access to all terminals:

  • Merge all terminals in a single pane, or move each terminal to its own pane, taking advantage of the new split terminals feature.
  • Terminals could auto-create a basic configuration based on your active terminals.

The proposed APIs look as future proof as they can possibly be to me.

@Tyriar
Copy link
Member Author

Tyriar commented Apr 5, 2018

This is needed for #46192

@Tyriar
Copy link
Member Author

Tyriar commented Apr 12, 2018

This is landing in tomorrow's insiders as a proposed API:

export namespace window {
	/**
	 * The currently active terminals or an empty array.
	 *
	 * @readonly
	 */
	export let terminals: Terminal[];

	/**
	 * An [event](#Event) which fires when a terminal has been created, either through the
	 * [createTerminal](#window.createTerminal) API or commands.
	 */
	export const onDidOpenTerminal: Event<Terminal>;
}

@vscodebot vscodebot bot locked and limited conversation to collaborators May 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api feature-request Request for new features or functionality on-testplan terminal General terminal issues that don't fall under another label
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants