Vscode: deprecated : explorer.openEditors.visible = 0

[gpuido]

The release notes of 1.20 seems to indicate that we won't be able to set the visibility in settings.

Please, keep a parameter to completely hide the OPEN EDITORS view.
This is a key aspect to deploy the editor and imply our way to use it.

from https://code.visualstudio.com/updates/v1_20#_open-editors-updates :

The ability to set explorer.openEditors.visible to 0 to hide the OPEN EDITORS view is being deprecated in the January release and we plan to drop it in February. To hide the OPEN EDITORS view, use the context menu in the Explorer title area to control the visibility of views.

• VSCode Version: 1.20
• OS Version: Windows

Thank you,
Guido

[isidorn]

@gpuido users can now right click to hide the explorer view.
What you seem to want is API to hide views, which we do not provide. I will rename this to be a feature request regarding that. We will not bring back the hack to hide the open editors view.

fyi @sandy081

[gpuido]

@isidorn Do you mean that we will need an extension targeting a future API to
hide 'open editors view' without user right click ?

Setting the view visibility is, well, a setting.
Why can't we just have "explorer.openEditors.visible": false in user settings ?

[gpuido]

I mean, I don't need an API. I just need "explorer.openEditors.visible" being still available in the next version.

I don't use tabs either and use "workbench.editor.showTabs": false the same way.

[isidorn]

If you are a user, you can just right cclik on that view to hide it as shown in the gif.
If you are an extension, we need to add api for this to be possible.
Which one are you?

[gpuido]

A user.
User settings are here to avoid clicking around to setup our coding environment.
That's why I don't understand why this is deprecated.

visibility settings are the first thing anyone configure in user settings.

Please, keep that one too.

[isidorn]

Nope. Please just hide it in the split view, we preserve this across workspaces, so you will only need to do it once as a user.
Closing as designed.

Thanks for feedback

[usernamehw]

@isidorn, does this mean that deprecation is already done (in Insiders or(and) Stable?) and functionality in its final form?

[gpuido]

@usernamehw look at https://code.visualstudio.com/updates/v1_20#_open-editors-updates

[usernamehw]

The ability to set explorer.openEditors.visible to 0 to hide the OPEN EDITORS view is being deprecated in the January release and we plan to drop it in February.

we plan to drop it in February - is it referring to February as month or release? I, personally, don't know.

[gpuido]

Deprecated means it will disappear in the next stable version.
I haven't check if it's already done in insider.

[gpuido]

February release.

[isidorn]

It is already removed in the insiders.
It will be removed in the next stable which we plan to ship start of march.

[gpuido]

@isidorn Don't you feel it's a bit weird to remove a basic visibility setting like this ?
somewhere, in a file, the setting will be set once we right click on it and hit hide.

vscode have always been about a clean slate to start with.
I personnaly use the tree+editor+terminal. No Open editor view, no tabs.

[gpuido]

@isidorn I have reset the title since it was a renamed on a misunderstanding.

[vcsjones]

I agree. This should continue to work in the user's settings.json file. This isn't about an API, this is about this in the JSON file.

"explorer.openEditors.visible": 0

I very much liked that with a simple JSON file my exact VSCode preferences can be restored. That makes it easy to set up new environments, virtual machines, etc. I keep this file in a gist and keep it up-to-date.

It's disappointing that the setting will no longer be respected. This also sets a bad precedent that full-customization and preferences is no longer portable in a JSON file.

[dustinmoris]

I agree with the others here. I don't understand what was wrong with this being a setting in settings.json. I thought was wonderful for the exact same reasons as others suggested. I can sync my editor across multiple environments with a single file. It's wonderful. What is the benefit of a right click if I may ask?

[isidorn]

Thanks for your feedback. The benefit or right click is that it behaves like any other view in all the other split views (debug views, custom views in explorer).
For those views we do not have settings to hide, so in the same way open editors will not have a special visibility setting.
All of this is done for consistency and for removing special code that had to deal with this.

[dustinmoris]

The other views are not on by default though. So when I set up a new environment I don't need a setting to remove all annoying views, because they are not on by default. So if consistency is key here, then the open editors view will be hidden by default? If yes, then I don't mind, otherwise it's a really annoying thing. It will be like Visual Studio where the first thing you do after opening is to hide all the side panels which you never use and where I know the key combination anyway to pop it open if I need it...

[isidorn]

@dustinmoris if you hide it once it will be hidden forever in all workspaces.
By default it is shown.
Debug views are also there by default.

[dustinmoris]

Ok I see. I understand how this makes sense, however I personally think it would have been better to create consistency the other way around (even though that would have been more work). Instead of having no settings for windows at all anymore I think it would have been awesome to have settings in settings.json for all windows. There is huge value in being able to have my VS Code settings synced to my Google Drive and if I set up a new dev machine somewhere else I have my entire VS Code environment configured the same way again in which I am the most productive, including the layout of all windows, where I have my debug console, if open editors are on/off, etc.

Also this feature wouldn't be an all or nothing. I think it would be nice to still keep the right click functionality, but instead have it saved into the user's settings file. Essentially you save the state somewhere anyway, so might as well save the state into a place where the user can benefit from it.

Maybe the PM of VSCode can think about this ^

There is a reason why VS Code has become so popular so quickly. The more "hackable" it is by a user, the more it remains the editor which people went for in the first place.

[Tyriar]

@isidorn I really think this should still be a setting (number or boolean). In 1.20 I pull my settings.json file in and the workbench is exactly as I want it, in 1.21 it looks like this:

[isidorn]

@Tyriar we will have a transition strategy, if you had a setting we will write it into your local storage. Once I push the transition strategy I will close this issue.

[Tyriar]

@isidorn the main point is I work on many different machines and pull in my settings file on all of them, the transition strategy of converting the setting would eventually be removed and I would be left with the open editors pane that I have to close manually on every new machine.

This seems like one of those big decision sort of things that we should persist in settings.json so its portable?

[isidorn]

@Tyriar I agree with you that it is nice to have this portable. However I still hold the reasons I specified above, consistency and open editors not being special than other split view
Bottom line I hate spanding more of my time on this when I have actual work to do. So I will revert my commit and bring back the open editors visible 0.

Thanks for feedback

[gpuido]

Thank you @isidorn for bringing it back.

I understand the consistency reasons.
This somewhat relate to the history of the open editors view (working files!) as an alternative to tabs.

Sorry that you had to bring back all this code
as deleting old code brings so much satisfaction. =)

[dustinmoris]

@isidorn Also would like to say thanks to you! Really appreciate that you took the time to explain the consistency issue and your willingness to revert the change even though I can see that this is perhaps not the best solution to the problem!

You guys are doing a fantastic job with VS Code, it has certainly become one of the most popular editors not only amongst .NET folks but also among the wider developer community! Thanks everyone involved in it!