Reintroduce "explorer.openEditors.dynamicHeight" : false

[DavidBabel]

The "explorer.openEditors.dynamicHeight" options set to "false", allowed behind the scene to fix the size and make the explorer never dynamically moves.

To see the problem, lets say i want to open vast2.js, vast3.js then vast4.js :

As you can see i made many annoying miss clicks. And what you may not have seen is that i constantly choose a wrong other file just after opening one.

This is the most annoying behaviour of vscode UI and you just remove the only way to prevent that.

This behaviour, drive my all team crazy this morning. I choosed not to update just for that.

Have pity

[isidorn]

@DavidBabel thanks for your feedback You can now set "explorer.openEditors.visible": 0 to make the open editors view never automatically resize. And then you have to manually resize it using the sash. Can you try that out and le me know what would still be missing for your experience?

Apart from this we will fix the open editors to only expand with a delay, so the double clicking behavior gets better (the issue you demoed in your gif).

[DavidBabel]

For me "explorer.openEditors.visible": 0 hide completely the open editor panel. I'm not sure that's the expected behavior. Here is the result of what you propose :

Event if I resize manually the editor, it always keep and automatic resizing behavior which is very annoying. Nothing close of a fixed panel.

[isidorn]

@DavidBabel you are correct. Appologies the change is only in vsocde insiders. Can you please set "explorer.openEditors.visible": 0 in vscode insiders and try it out there. It will never grow, however it will still shrink (as you show in the gif). Personally I do not find this as a huge drawback. Having open editors at an exact fixes size any more is not supported, it is simply a design decision due to this feature reqeust https://github.com/Microsoft/vscode/issues/491

[stuartgibson]

Not being able to have a space between open editors and the project tree removes the ability to clearly delineate the two sections, as well as removing muscle memory for where the project tree starts. The arguments presented in #491 seem to come down to “why would anyone want whitespace?”

[DavidBabel]

continued here : https://github.com/Microsoft/vscode/issues/40638#issuecomment-367349173

[DavidBabel]

@isidorn You suggest to move the discussion on other thread, but since it's now closed, i'm following the disccussion here.

This is what @hedefalk wrotes :

Trying to understand what's going on here. Can somone explain how I can have a fixed size in any way with latest vscode? I always end up with lots of open editors and I don't want my workspace to be squished down like this:

Setting "explorer.openEditors.visible": 0

to hide completely is not what I want, I want something like 5 files always and a scrollbar.

===

And i totally aggre with him

[DavidBabel]

For me when you put this option : "explorer.openEditors.visible": 4 When you have 2 files loaded, you should have 2 blank spaces below the open ones.

If it's not a wanted behaviour for everyone, the option explorer.openEditors.dynamicHeight still makes sense.

This option fixes all vscode strange file open behaviour

[bartmichu]

It worked perfectly for me with explorer.openEditors.dynamicHeight but it is super annoying now when this setting is no more.

@isidorn how many users decided to disable telemetry? I'm one of them so count 220+1.

[meyermack]

Until this gets fixed, one workaround is to drag the whole "Open Editors" section down to the bottom. Not ideal, but at least the main file tree stops dancing around.

In fact, I wonder if keeping the file navigation tree stationary as Open Editors expands and contracts would solve this for most people. It's really the only problem I have with current behavior. The current behavior is really bad when you open a large/complex file on a slower computer. It can take a second or more before the file opens and the current item under the mouse coyly slips away.

[mtman]

@isidorn Adding a delay may be slightly better in one case, but if I'm focused on the file content right after the file gets open and then immediately move back to Explorer, just when the delay runs out, the delay has a negative effect.

I cannot see how the resize feature prevents having the panel pre-filled with blank lines. explorer.openEditors.visible already behaves as both resizable maximum and fixed minimum for non-blank lines.

Please consider removing the "needs more info" tag.

[DavidBabel]

This behaviour still drive me crazy ><.

The only option i found is to put the open editor at the bottom, but it's no so handy

[anderson-custodio]

The usability was compromised removing explorer.openEditors.dynamicHeight: false. Now is easy to be induced to click in the wrong file. Maybe would be nice to restore the last behavior (fixed height with scroll bar).

[Bigdragon13th]

Any update on this? This also drive me crazy since they remove that ability.

[joaodforce]

This subject is also driving me nuts, every time I want to double click a file the first click previews it and then the file tree shifts down and i click the file above. This is a serious usability issue.

[webmasterMeyers]

I also want the old behaviour back, fixed height with a scroll bar

[icirellik]

Was there a reason for removing a working and useful feature, I would love to have this back as well.

[DavidBabel]

@icirellik It's now in the general backlog, it may be reimplemented some day

[AndreaCatania]

I would like that the Open Editors panel has a fixed size; exactly like the Outline panel.

I come from QtCreator and I'm really used to not use Tabs, but rather organize the files in this little list, but since in VsCode the panel keeps changing its shape I'm not able to memorize its position and is really uncomfortable for me.

I hope that this feature is added any time soon.

[lramos15]

Going to mark as duplicate of https://github.com/microsoft/vscode/issues/128508 as I feel #147771 will fix both of these issues

[icirellik]

@lramos15 after playing around with it for a bit; I think so too! So happy to have this functionality again!