Support for split terminals

[fabiospampinato]

The latest Visual Studio Code release (v1.21) added support for split terminals:

I think it would be great to add support for them to this extension.

Maybe we could add this new configuration:

"split": "My Other Terminal" // Split this terminal instead of creating a new one

If present, instead of creating a brand new terminal, we'll split, in this particular case, "My Other Terminal".

What do you think about it?

---

Edit: We need microsoft/vscode#45407 in order to implement this.

[soneymathew]

There can be multiple splits across multiple terminals with depth = 1. so a nested terminals array will work?

terminals: Terminal[] | TerminalGroup[] ?

[fabiospampinato]

@soneymathew are you proposing that instead of this:

{
  "terminals": [
    { "name": "a" },
    { "name": "b", "split": "a" },
    { "name": "c", "split": "b" }
  ]
}

We should do this?:

{
  "terminals": [
    [
      { "name": "a" },
      { "name": "b" },
      { "name": "c" }
    ]
  ]
}

That could work, but I want to use grouping in a future update for supporting better terminals organization, basically doing something similar to what Projects+ is doing:

I could implement both kind of groups but I think that would be confusing.

[Tyriar]

Something to keep in mind is that eventually we may allow splitting in both direction and nesting pane groups, so you could have a 3x3 grid for example. I don't think we will touch on this idea further until there's a real need for it, for example if you could pull the panel/terminal out into a different window microsoft/vscode#10121. Whatever you land on, make sure it's relatively compatible with this possible future direction 😃

[fabiospampinato]

@Tyriar 2d grids would be great. I think in order to support those this extension would only need to know the direction of the split, so the configuration could become:

"split": ["foo", "bottom"]

or a new configuration key could be added:

"splitDirection": "bottom"

Thanks for point that out 👍

[Tyriar]

@fabiospampinato the orientation is referred to as vertical (when stacked to the right) and horizontal (when stacked on the bottom). Also to add more complexity, the orientation is rotated when the panel is moved 😄

[fabiospampinato]

@Tyriar As long as there'll be an API for knowing in which orientation the panel is it shouldn't be a problem to add support for this. I'll probably just give the user enough powers for setting up the grid however he/she likes, potentially having completely different grids in different orientations.

[cassvail]

This feature would be great!
Why not a simple splitCommands conf in the terminal configuration?

"terminals": [
    {
      "name": "a",
      "command": "command",
      "splitCommands": [
        "command2",
        "command3"
      ]
    }
  ]

This would allow to define which terminal will be splitted and the split order

[fabiospampinato]

@cassvail What do those splitcommand1 and splitcommand2 represent in your proposed configuration?

IMHO this kind of configuration looks better:

{
  "terminals": [
    { "name": "a" },
    { "name": "b", "split": "a" },
    { "name": "c", "split": "b" }
  ]
}

It allows you to declare which terminal you want to split (the terminal whose name is the value of split), and the split order too, since that all terminals are inside an array (but that's not really necessary for this to work).

[cassvail]

@fabiospampinato The split command would be a cli "command" (i.e. "npm run test")
In my suggestion there's the configuration for only one terminal (I re-edited to match your suggestion)

Having the "split commands" inside one terminal, would allow to launch just one terminal config and open this terminal already splitted and running the splitCommands list.

As I'm explaining the request, I understand that probably your configuration is correct, if the objective is running "one or all" terminals and automatically going to split an existing terminal.
Even if I see an issue in your example (what if I Run Single "a" and then Run Single "c", the "b" terminal is not available)

My request probably could be another PR...
What I mean is what if I want to launch a "group" of terminals, but not all, with just one command? That's why I proposed the splitCommands inside one terminal.
Depending on the project i might need to launch a subset of terminals in a splitted window, but without opening them one at time with Run Single.

I hope what I wrote makes sense to you. Thanks

[fabiospampinato]

@cassvail I see your point. We'll fix this by adding support for groups.

what if I Run Single "a" and then Run Single "c", the "b" terminal is not available

I see no easy fix for this, if the target terminal is not available there's nothing to split. We could add support for multiple split targets, so that we'll split the first one available, but I'd rather keep the configuration simple than fixing this problem, which IMHO is not a big deal.

[soneymathew]

@fabiospampinato The more I thought about terminals: Terminal[] | TerminalGroup[] ? the more likely it can limit future evolution paths

Perhaps another way would be to separate the grouping from the terminal definitions via layouts config, Do we need to give ids to each terminal for this ? or the name can be considered unique?

{
  "autorun": true, // Execute `Terminals: Run` automatically at startup or when the project is added to the workspace
  "autokill": true, // Kill all the terminals created from this configuration when the project is removed from the workspace
  "env": { "name": "value" }, // Global environment variables that will be applied to all terminals
  "terminals": [ // Array of terminals to open
  ]
  "layouts" : [ ] // Array of layouts , this is optional , if omitted the extension will fall back to current behaviour
}

Which could facilitate a few new use cases in the future as well.
@Tyriar is it safe to assume that VSCode might decide to let the user slice and dice the space available for the terminals in whichever way they want. Possibly even support a flex layout or a grid layout

Types of layouts commonly seen
Vertical slices (this could evolve to take percentage spacing per terminal)
Horizontal slices (this could evolve to take percentage spacing per terminal)
Tabs of Terminals
Groups of Groups
For when a layout can be nested within another layout
not sure how the config can capture this
Reuse terminal definitions
For a possibility of referring to existing terminal definitions in the terminals Array

[fabiospampinato]

Do we need to give ids to each terminal for this ? or the name can be considered unique?

The target configuration option already uses a terminal's name in order to uniquely identify terminals. When groups will be implemented I think we could use a "selector" instead, something like group1.name, in order to distinguish between different terminals with the same name.

Which could facilitate a few new use cases in the future as well.

I think providing a way to define different layouts for different orientations of the pane (there's no API for this yet, microsoft/vscode#47062) would be enough, if you have a compelling use case in mind, that would require a more powerful configuration, I'll be happy to hear it.

For a possibility of referring to existing terminal definitions in the terminals Array

This would be interesting, currently blocked by microsoft/vscode#13267.

[Tyriar]

@soneymathew

is it safe to assume that VSCode might decide to let the user slice and dice the space available for the terminals in whichever way they want. Possibly even support a flex layout or a grid layout

The model I have in mind is containers like you can have now but you can nest them within each other, which is kind of like nest flex layouts. Grid: no since you can accomplish the same thing using this model.

[jomel]

I would be very interested to see this implemented.
Even in a non-configurable-MVP for now (ie only allow vertical single-level splitting)

[mrfloppi]

So @fabiospampinato what's the status on this? 🙂

[fabiospampinato]

@mrfloppi we are still waiting on microsoft/vscode#45407 to be addressed.

[jhonathas]

Hello, was this feature continued?

[ni-mkrieg]

Does the last comment in that issue above help?

[ni-mkrieg]

Does the last comment in that issue above help?
microsoft/vscode#45407 (comment)

async createNewSplitTerminal(): Promise<vscode.Terminal> {
    return new Promise(async (resolve, reject) => {
      await vscode.commands.executeCommand("workbench.action.terminal.split");

      vscode.window.onDidChangeActiveTerminal((terminal) => {
        if (terminal) {
          resolve(terminal);
        }
      });
    });
  }

[ildemartinez]

I am using this great extension but will be desireble to have split termanals because it will be very useful to see the information of all terminals at once....how is this feature going?

[fabiospampinato]

how is this feature going?

I don't think the required APIs for implementing this are there yet.

[tjx666]

Does the last comment in that issue above help?
microsoft/vscode#45407 (comment)

async createNewSplitTerminal(): Promise<vscode.Terminal> {
    return new Promise(async (resolve, reject) => {
      await vscode.commands.executeCommand("workbench.action.terminal.split");

      vscode.window.onDidChangeActiveTerminal((terminal) => {
        if (terminal) {
          resolve(terminal);
        }
      });
    });
  }

It's too long to wait the official API to publish, any problems to using this way? @fabiospampinato

[fabiospampinato]

@tjx666 maybe that's good enough but I don't currently have the time to work on this.

[globalhuman]

Looks like the vscode ticket has now been merged. Has that unblocked this feature?

microsoft/vscode#45407

[tjx666]

@fabiospampinato

[fabiospampinato]

Implemented in v1.15 🎉

There's a new configuration option for each terminal called "split", where the value should be the name of an open terminal, if you use that will create a split!