Allow customization of the default panel height

[Tyriar]

Testing: https://github.com/Microsoft/vscode/issues/14297

Since the panel does not auto size to the content like the sidebar does (when double clicking sash), it makes sense to be able to set how large the user wants the default panel to be.

Some things to consider:

• What if the user uses vscode on both horizontal and vertical monitors?
• Perhaps it would make sense to allow both percentage-based and absolute values?

Related: https://github.com/Microsoft/vscode/issues/13898

[jordwalke]

In the case of the terminal, I wish for a mode that would allow the terminal to be quickly maximized to consume the entire room of the editor tabs. Would this be possible with a setting of 100%?

[Tyriar]

@jordwalke this is pretty much available by my other request to add a maximize panel command. Try keybinding workbench.action.toggleMaximizedPanel, here's mine:

{ "key": "ctrl+shift+q",    "command": "workbench.action.toggleMaximizedPanel" },

You can also run this command from the command palette. It doesn't set it to 100% but it's pretty close.

[jordwalke]

Thanks, I was aware of that command and I tried it, but I was curious if it could be configured to make the panel 100% of the height so that it even covers the tabs. Occasionally, I want to switch into some heavy terminal work. I looked at the code and it just seems like it uses the hardcoded minimum editor height.

[Tyriar]

I believe the reason it's not 100% is because it would be difficult to unmaximize if it was maximized accidentally. The workbench.action.toggleMaximizedPanel command itself is not surfaced anywhere on the UI (to avoid bloat). /cc @isidorn

[jordwalke]

That makes sense. I hear more customization over all the panel layouts is coming soon? I could also imagine a small toggle maximize button on the terminal panel which would open up the ability to have maximizing take up 100% of the available space.

[Tyriar]

Some customization will hopefully be coming soon yeah, you'll probably want to follow along with https://github.com/Microsoft/vscode/issues/2806 too

[jordwalke]

Why can't panel/pane/split management be made customizable to plugins?

[Tyriar]

The DOM is restricted to promote stability/performance, see https://code.visualstudio.com/docs/extensions/our-approach

[jordwalke]

I do agree with the general approach of VSCode. There's many opportunities that it opens up including the ability to render VSCode with a much faster non-DOM rendering engine. But can't something like extension-driven panel layout be achieved without having access to the DOM? For example, you could imagine an extension which could even be ran out of process, which controls/determines how panels should be rearranged. For example, I have a Vim plugin that, when focused on a vertical split, will automatically resize that vertical split to match the longest line in that file, and then distribute the remaining space among the other vertical splits. That doesn't involve any direct DOM access, but just requires that extensions be able to partake in arrangement/space calculation.

[Tyriar]

But being able to resize the panel won't accomplish more than what the maximize command can do right now as the boundaries are defined to disallow hiding of the editor. As for moving the panel to the side of something, there's no easy way to do that without DOM manipulation unless we add it (which has a host of knock on effects).

[jordwalke]

Suppose the plugins were given the ability to have the panel cover the entirety of the tabs area, so that the terminal panel was consuming 100% of the space. You pointed out some reasons why this might not be desirable to include as the built in behavior, but if performed by a plugin, I think it could be justified. The user installed the "cover-the-entirety-of-tab-area-with-the-panel extension", so they kind of agreed to accept the downsides. There could be some really creative things that extensions authors could do layout the panels/tabs/splits and many of them are pretty customized solutions that wouldn't really make sense to include in VSCode out of the box.

[Tyriar]

Let's see what @isidorn thinks who owns that part of the workbench.

[jordwalke]

Also, I had some ideas for extensions with custom workbench layout that would integrate the terminal work that you're doing with VSCode to create a more immersive terminal experience. Some of these would really benefit from being able to request that they be positioned in a particular way. Just a couple of ideas off the top of my head:

• Ephemeral terminal tasks: When opening a package.json file, expose a command to open open a terminal to the right of that split, and run npm-check, or npm update command inside a lightweight terminal. Expose global hotkey to close any and all "ephemeral" terminal windows.
• Ephemeral full screen terminal window for git diff views. I am interested in being able to temporarily maximize the panel to consume 100% of the editor real estate (not the side/toolbar area) to show side by side diff tools using vimdiff.
• Full screen terminal integration for Ranger file browser. Imagine being able to open ranger in a temporary 100% sized terminal window to pick a file, and then attach a ranger hook so that when chosen, it would open up in VSCode.

These are just the few that I had thought of recently, but when the community is given the ability to create their own layout/workflows they think of ten times more than I am able to consider.

[jordwalke]

As another anecdote, Vim allows full customization of layout of panes/tabs/splits, via its extension system, yet it does not allow access to its underlying drawing/"DOM" framework (which is something more like ncurses in its case).

Roughly, it allows manipulating of arbitrary horizontal/vertical splits which all belong to exactly one tab page.

+-------------+-+-------------------------+
| Tab1 | Tab2 |                           |
|      +------+----+----------------------+
|                  |      Tab1            |
|  Tab1            |      VSplit2         |
|  VSplit1         |      HSplit1         |
|                  |                      |
|                  +----------------------+
|                  |      Tab1            |
|                  |      VSplit2         |
|                  |      HSplit2         |
|                  |                      |
+------------------+----------------------+

I'm not suggesting this exact feature for VSCode, but just giving another cool system to look into. IMHO, writing Vim extensions for managing these splits/tabs is far too complicated, but that's not inherent in their design - in Vim's case the problem is more a lack of decent APIs to manipulate them. Maybe VSCode is a chance to do it right?

[jordwalke]

Another very short-term improvement which needn't wait on general workbench layout capabilities, is to allow the terminal panel to consume 100% of the tabs space if no tabs are currently open. If closing the last tab, while the panel is maximized, it would also have the terminal panel consume the available remaining space. This is a small improvement that would improve the experience until general pane management becomes more powerful.

[jordwalke]

And another reason why it might be nice to emphasize customizability of terminal pane layouts, is that it allows integration with many great existing tools that are already built for the command line, none of which bloat VSCode itself. For example, a tool like vimdiff can be used to view side by side, readonly, diffs of text, and ranger/midnight commander can be used to browse the filesystem and move files around. We also have various dashboards and graphical ncurses programs that monitor builds/test cases. A focus on allowing terminal panels to integrate very nicely into the workflow (with plugins that can manage their layout) decreases the need to write expensive JavaScript/DOM based extensions which harm app startup time.

[jordwalke]

Also, I just realized that if the terminal window is maximized to 100%, you can drag it back down with the mouse (hovering at the top of the panel displays the drag mouse icon and you can restore it).

[Tyriar]

I doubt customization on that sort of level would come any time soon, cool ideas though. You would probably want to follow along with https://github.com/Microsoft/vscode/issues/7504 and https://github.com/Microsoft/vscode/issues/10546 in addition to https://github.com/Microsoft/vscode/issues/2806.

Personally I find the maximize panel button so useful that I think it's worth reserving space on the panel buttons at the top, which would make it easier to justify 100% height. However, that would probably mean including it on all the panels, increasing bloat and complexity of the UI. It's only really useful in the integrated terminal and maybe the output panel as well.

Ephemeral terminal tasks

Something similar to that is happening right now by moving the tasks framework to use the integrated terminal https://github.com/Microsoft/vscode/issues/15584 https://github.com/Microsoft/vscode/issues/18312

[jordwalke]

Okay, perhaps I'll just experiment with some customized layouts in a fork for now. It really does seem like the way to keep VSCode bloat free, is to provide basic (not highly customizable) layouts out of the box, but then open up customizable positions/splits for panels at the plugin layer (without allowing DOM access).

[jordwalke]

Ephemeral terminal tasks

On that note, does any of the planned work include the ability to handle particular file types in the terminal? Suppose I want to make it so any time I double click on a particular file in the explorer, it might open up in a terminal, with an appropriately configured terminal task. Will this be supported? (Likewise from the quick open dialog).

[Tyriar]

does any of the planned work include the ability to handle particular file types in the terminal?

I think you can hook up explorer context menu actions using the extension API (I don't think you can touch double click) and the terminal API right now lets you send text to terminals created specifically by the extension, a bunch of improvements to the API are incoming due to the tasks system moving to using it though.

You could make a command that does something in the terminal based on the current file though, enabling something like this:

1. Open a file
2. Press some keybinding to run your extension command
3. Launch a terminal and run some command

Terminal reuse is incoming which would fix the issue of launching a new terminal every single time https://github.com/Microsoft/vscode/issues/18377

[jordwalke]

Cool. I could also imagining adding a hook for new files that are opened in tabs so that you can run terminal commands automatically when they are opened right?

[Tyriar]

Yeah I think there's an event for when a file is opened

[isidorn]

Accepting PRs that fix this Code pointer https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/browser/layout.ts#L26

[vscodebot[bot]]

This iteration we focus on issue grooming. This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[plwalsh]

@Tyriar Is there any current way of handling this problem? I like to keep my terminal panel at a fixed height across all of my VSCode windows/workspaces. And ideally, that height is around 1/3 of the overall window height. The current default height that I see when double-clicking the sash is just too high (roughly 40% of overall height). And any time the panel height gets out of whack, due to a wonky VSCode reload, a VSCode update, or a misproportioned ratio from an un-maximized window, it's a painstaking process to get all my workspace panels back to identical heights where I want them. Is there no setting for a fixed panel height or custom default height? Thanks!

[Tyriar]

@plwalsh not right now, but terminal tabs in the editor area are on the horizon which I think are a little easier to manage the size of.

[BenChand]

I use visual studio code without the use of my hands and resizing the panels is a constant problem i have - All i really want is for the default terminal window size to be a customizable fixed size so that i can stop emulating the pixel perfect accuracy needed to resize the panes with tedious voice commands

[Tyriar]

@BenChand but once the panel is resized it's saved and used everywhere?

There's the "toggle maximised panel" command which you might find useful if you temporarily want it to be fullscreen.

[BenChand]

@Tyriar Having the same panel size be used everywhere would be good enough for me. Normally I want half of the vertical screen to be code and half the vertical screen to be the terminal so that i can read build errors :) I saw the toggle maximized panel key binding mentioned here, which is a nice start!

[plwalsh]

@BenChand but once the panel is resized it's saved and used everywhere?

I have found this is not always the case. Nominally, yes, once the panel is resized, it does get saved and used everywhere. But there are many times when I'll open a workspace (sometimes after a vscode-insiders update or a window reload), and the panel will jump to some random height (usually somewhere just short of maximized). And getting the panel back to where you want it is indeed tedious.

[Tyriar]

Normally I want half of the vertical screen to be code and half the vertical screen to be the terminal so that i can read build errors

Soonish we will likely bring support "terminal editors" which will let you move a terminal to the an editor group to the right while keeping the panel on the bottom. That's tracked as part of https://github.com/microsoft/vscode/issues/10546

But there are many times when I'll open a workspace (sometimes after a vscode-insiders update or a window reload), and the panel will jump to some random height (usually somewhere just short of maximized). And getting the panel back to where you want it is indeed tedious.

Thoughts @sbatten?

[sbatten]

It would help if there were a clear repro here on when the panel is "some random height". the panel height is remembered as an absolute size not a relative size, so its possible if you have a really large window and terminal and then restore a small window, that the terminal becomes a larger portion of the window.

[plwalsh]

@sbatten The inherent randomness of it makes the clear repro a bit difficult to ascertain. I haven't been able to figure out the why or when it happens; it just.. happens. I've thought about it being linked to restoring a small window; however, every time I open a new window, it always opens small, even though I always use my workspaces maximized to my full monitor size (and I close them from maximized too). So that's the randomness -- they always open small, but only sometimes it throws off the panel height.

I also don't know how to view the absolute panel height at any given time, in order to capture that as a data point.

[sbatten]

window.newWindowDimensions

This setting controls how new windows are sized. As the description says, if no window is opened, we will restore the last window size but if you open a second window, this setting controls that behavior. Perhaps try setting this to inherit or maximized if that is your primary use case.

[plwalsh]

Thanks for pointing that out, @sbatten. I hadn't known about that setting, so I'll give it a try and see if that helps the rare panel height jumping.

[steveoh]

I wish I could set the workbench height by number of lines or something like that. 10rem or so would be great.

[starball5]

Related Stack Overflow question: How can I configure the sidebar and panel's default sizes in VS Code?

[digitalsignalperson]

I've been using a 42" 4k screen and really like having the panel position default to the left, taking advantage of the space. When I press C-j, I get the terminal panel pop out, and it feels similar to a "Split left" pane, but I love that I can open/close it with the hot key quickly.

When the panel is on the left or right side, the default width is super thin. The command prompt ends up spilling over into multiple lines and is very awkward. Using the mouse to drag the panel also requires some precision. I wish there was a keybind to just increase/decrease the panel size.

It seems like sometimes when I open a new code window, it remembers the panel width of the last window, but it's not consistent for me. Other times it opens with very thin like 300 pixels width. I tried watching to see where this might be remembered but couldn't find anything (inotifywait -r -e modify,create,delete,move ~/.local ~/.config -m)

edit: I think maybe buried in the likes of ~/.config/Code - OSS/User/workspaceStorage/350c730fd2358ec3878ed286826debc9/ MODIFY state.vscdb