When the setting explorer.openEditors.dynamicHeight is set to false the "open editors" panel should have a fixed height. This is not working on this version. On 1.19 (stable) is working fine.
Steps to Reproduce:
explorer.openEditors.dynamicHeight to falseReproduces without extensions: Yes

On the left is 1.20, on the right is 1.19.
Both are with the explorer.openEditors.dynamicHeight set to false and explorer.openEditors.visible set to 3.
@isidorn can we now resize the open editors view?
@bpasero yeah a user did it and it actually behaves fine. Try it out.
I should probably dump the dynamicHeight flag though
@isidorn really? :O
I really like this option :/
@beeblebrox3 what do you like about this option that the current solution is not supporting?
@isidorn what is the current solution? I know only the two settings above.
What I like is that this panel always has the same height (enought space for 3 tabs), regardless of the number of open files. This setting is what do that for me. We have another way? 馃
Thanks!
@beeblebrox3 currently we do not support having open editors be a fixed height. The reason for this is that I believe more users want the feature that the open editors can be resized when the overflow, than having it always the same.
I will verify this hypthoesis by looking at telemetry
@ramya-rao-a I just tried running the following query at kusto, it always says loading, is there somethign wrong I am doing?
let Settings = VSCodeEvents
| where timestamp > ago(7d)
| where name == "monacoworkbench/updateConfiguration"
| extend dims = parsejson(customDimensions)
| extend machineId = tostring(dims['common.machineId']), keysString = dims.configurationKeys, keysType = tostring(dims.configurationSource)
| extend ver = tostring(dims.version)
| summarize argmax(timestamp, keysString) by machineId, keysType
| project machineId, max_timestamp_keysString, keysType
| summarize dcount(machineId) by tostring(max_timestamp_keysString), keysType
| project max_timestamp_keysString, keysType, AllMachines=dcount_machineId
;
Settings
| extend Keys = split(substring(max_timestamp_keysString, 2, strlen(max_timestamp_keysString) - 4), '","')
| mvexpand Key = Keys
| where Key == "explorer.openEditors.dynamicHeight"
| summarize Machines=sum(AllMachines) by tostring(Key), keysType
| sort by Machines desc
| limit 100
@isidorn On the stable we can do this. Maybe we can support both ways. Its possible?
My problem with the dynamic height is that when a new tab opens, the files panel moves. Is very annoying when I'm using the mouse to open files. Sometimes I do this.
This guy has the same problem:
https://medium.com/@fridrik_10474/thanks-didnt-know-about-the-explorer-openeditors-dynamicheight-887820cc2c10
@beeblebrox3 I understand the use case. For that you could use a smaller openEditor.visible number and as soon as that is hit the open editors will no longer grow. You will have to manually resize it
Try explorer.openEditors.visible: 3 for instance and let me know how it goes.
@isidorn I know, I use it too. With the value 3, by the way. But it will only solve my issue when I already have 3 open files :/
@bpasero checked kusto and currently 220 users use this setting, both in insiders and stable. I do not think that is a large number compared to our total number of users
@isidorn I agree. But I think that vscode has a lot of settings and people just don't know all of them. I don't, at least.
We have an issue about this change? Maybe with more than 220 upvotes? 馃
I have removed the support for dynamicHeight completely and documented this in our release notes
Why remove a feature, when it had value for users? I really hate that the file list is moving from under the cursor. Let's assume that you want to open 6 files. Click on the first one, then, argh, files moved under the mouse...removing this feature I guess will lead that 220 users to set the open file list to size of 0 to achieve something "similar" (NOT!) :-S
I was (probably) one of the 220 people, and found this issue out of frustation after the 1.20 update. Here is my alternative solution to this:
I feel it would be better to allow the open editors list to be expanded up to the number specified in the explorer.openEditors.visible setting, even if the number of open editors has not reached this level.
This would effectively mean that the size of the open editor panel can be set to the size it would expand to automatically.
This can be achieved by updating this code in openEditorsView which calculates the min and max sizes, with my alternative.
Here is a video of this in action:
https://streamable.com/5ior5 *
I can make a PR if this is acceptable @isidorn
Notes:
: Maybe the explorer.openEditors.visible setting does not accurately describe the purpose of this value and the dynamicHeight setting would have to be reinstated. This is because when the number of open editors increases past the setting, the size of the panel will remain at that value in my current implementation. Without digging further into the source, I would not know how fix this.
*: Does anyone know a better way I can make and attach a suitable video?
I was (probably) one of the 220 people, too. Currently the best solution is, set the visible value to 0.
A PR is always welcome, but I would prefer if we first create one where we discuss what the problem is, what we want to achieve before doing any coding. So feel free to create that. Also I would wait a couple of days for the dust to settle after the release to see how many people are impacted by this.
Also from Monday, insiders will have some updates to the open editors view. So try it out there, and feedback based on that version would be the most valuable in the PR.
Thanks
OK, No Problem. I'll wait until Tuesday, see the change insiders get, then make a PR for discussion. Thanks for the quick reply!
@beeblebrox3 wrote: "when a new tab opens, the files panel moves". This is totally my case.
I see only one workaround to drag-drop "open editors" panel under "explorer" panel (to the bottom). In this case the new opened file resizes "explorer" panel from the bottom and does not shift items which is hovered by mouse cursor.
This approach is used in Qt Creator, but I more prefer to have "open editors" panel at the top of my screen.
Regarding your comment, @isidorn , I have a couple of questions:
1) You say that you would prefer the PR to only be discussion before any coding is done and commits are added. However, it is not possible, insofar as I can see, to create a PR without any commits. If this is an oversight, would you prefer a new issue to be created for discussion, or to reopen this issue.
2) There are supposedly changes to the open editors view in the latest insiders as of at least yesterday. I cannot obviously see any changes, at least which affect this issue, even looking at commits starting from the tag of 1.20.0 to the latest master. Would you mind laying out what these are.
Many thanks.
@DanMcNab there is an open issue for this, let's continue the discussion there. In the lattest comment in that issue I mentioned what is the difference.
https://github.com/Microsoft/vscode/issues/43501
did not see the reference, here is my message :
You all got my point.
Sadly it does not work on latest vscode insider either :

"explorer.openEditors.visible": 0 hide it completly.
It is a huge drawback when you are very fast opening files with mouse. This is my only mousepad usage in vscode, and trust me, this issue burn my mind.
I understand that default design behaviour may change with time. But you should let the choice of keeping legacy behaviour too. Since it's literally, removing an available setting.
This may be the first ticket about, may not be the last. My team drives crazy on this.
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.
@hedefalk this seems like an unrelated issue ot this one, please file a new issue with reproducable step how you get into that state and assign it to me. Thanks
Most helpful comment
did not see the reference, here is my message :
You all got my point.
Sadly it does not work on latest vscode insider either :

"explorer.openEditors.visible": 0hide it completly.It is a huge drawback when you are very fast opening files with mouse. This is my only mousepad usage in vscode, and trust me, this issue burn my mind.
I understand that default design behaviour may change with time. But you should let the choice of keeping legacy behaviour too. Since it's literally, removing an available setting.
This may be the first ticket about, may not be the last. My team drives crazy on this.