The work on tabs/stacks introduces a new bag of configuration settings. We should decide on the location of these settings and wording. Feedback welcome, I am not attached to the wording I picked currently:
workbench.showEditorTabs: _Controls if opened editors should show in tabs or not_workbench.previewEditors: _Controls if opened editors show as preview until getting pinned. Set to false to always open editors pinned_workbench.quickOpenPreviews: _Controls if editors opened from quick open show as preview. Set to false to always open editors from quick open pinned_workbench.editorOpenPositioning: _Controls where editors open. Select 'left' or 'right' to open editors to the left or right of the current active one. Select 'beginning' or 'end' to open editors independently from the currently active one._/cc @Microsoft/vscode
My two cents: for me a setting always reads easier if a verb is included. May be we missed the boat but would it be possible to group these under workbench.editor. So something like `workbench.editor.showTabs', 'workbench.editor.openAsPreview', 'workbench.editor.openPositioning'.
For the first iteration of settings is workbench.quickOpenPreviews really necessery? I would just start with workbench.previewEditors and if users ask then add quickOpenPreviews.
How would the behavior be if I set previewEditors = false and use quick Open and there is no setting. I would expect it to open as non preview as well. If that is the case then I think we don't need quickOpenPreviews unless users ask for it.
Why is it called a 'preview'? I find this confusing, especially as there is the Markdown preview.
what about
workbench.editorTabs.reuse': 'never', 'openFromExplorer', 'always'
If preview is confusing for people we should just use the term pin and just negate the setting. We do not use it anywhere else.
workbench.editorOpenPositioning
left Left of current tabright Right of current tablast Always lastSee also: https://chrome.google.com/webstore/detail/tab-position-options/fjccjnfkdkdmjohojoggodkigkjkkjhl
For people asking about all the options, yes we have individual users for each and every option I added (e.g. https://github.com/Microsoft/vscode/issues/5554, https://github.com/Microsoft/vscode/issues/2754, https://github.com/Microsoft/vscode/issues/6507 to control the preview behaviour).
Is it also possible to have the "open editors" in the explorer to be hidden?
@JostCrow yes, "explorer.openEditors.visible": 0
Thanks.
I also prefer to call pin it instead of not preview. It will be easy to understand that we are pinning it to the editor. Preview will be confusing as it has been used multiple places. For eg previewing a .md file will need more context.
Regarding settings, I would go for what @dbaeumer suggested, that looks well organized.
One more question to @bpasero and @isidorn
why are the values for the conf "explorer.openEditors.visible" is a number and how will I know what numbers are supported and what are they matched to?
@sandy081

The term preview is used to describe this behaviour in Visual Studio and in Sublime Text so it's not an uncommon term (Atom calls them Pending tabs). We could always rethink the way we use it for markdown files. However, if we go with pinned and unpinned tabs we could have settings like so:
"workbench.editor.unpinnedTabs.enableInExplorer": true,
"workbench.editor.unpinnedTabs.enableInQuickOpen": true
and anywhere else we want to enable unpinned tabs.
We should be aware though that we might have a need in the future to also support what Visual Studio calls pinned tabs - pinned tabs are positioned to the left hand side and newly opened tabs appear to the right of all pinned tabs.
@bpasero Ah its the # then.. I was confused with the setting key.. looking at it I felt its a boolean value.
In our discussion yesterday we started to settle on the use of the term preview tab given the prevalence of this term in other products.
We like the idea of a global setting to enable or disable the preview tab then specific settings for each area that might use the preview tab. We also discussed a setting that has a verb in it to better communicate what it does. So we might end up with something like
workbench.enablePreviewTab: true
workbench.enablePreviewTabInExplorer: true
workbench.enablePreviewTabInQuickOpen: false
which would turn preview tab on but disable it for quick open (so a file from quick open would open in a regular tab).
This approach would allow us to control how preview tab works in other UI in the future without needing to make any significant changes to the settings.
I pushed a change yesterday to not talk about pin or unpin throughout the UI to not introduce a new concept.
With working files we always had a notion of files that got added into the working files list and files which are not depending on the action that you do (e.g. double click). we take this concept a step further into the editor now. but the action that triggers this are still the same.
I got emotional feedback from Martin on the fact that we want to go with preview and I don't want to ignore his opinion (or any other) so maybe this particular UX item just needs a vote in the team to come to a conclusion.
For me the advantage of going with "preview" is that it is a term used in ST and VS already. A disadvantage however is that the name itself does not really imply what the visual impact is.
Thinking about the idea of calling it "reuse editor" had the advantage that it actually describes the visual impact this setting has because in the end this setting controls if an editor in the stack is being closed after opening the next one or not.
Thus I am also easy to go with "reuse" . Both terms are good for me.
I agree with @stevencl about _not_ using pinned (the term means something different in browsers as well).
I actually think that pending sounds okay, as in:
1. Not yet decided or settled; awaiting conclusion or confirmation.
2. Impending; imminent.
Thanks for the feedback. We settled on:
workbench.editor.showTabs: _Controls if opened editors should show in tabs or not_workbench.editor.enablePreview: _Controls if opened editors show as preview. Preview editors are reused until they are kept (e.g. via double click or editing)._workbench.editor.enablePreviewFromQuickOpen: _Controls if opened editors from quick open show as preview. Preview editors are reused until they are kept (e.g. via double click or editing)._workbench.editor.openPositioning: _Controls where editors open. Select 'left' or 'right' to open editors to the left or right of the current active one. Select 'first' or 'last' to open editors independently from the currently active one._@bpasero Thank you for your work!
Most helpful comment
How would the behavior be if I set previewEditors = false and use quick Open and there is no setting. I would expect it to open as non preview as well. If that is the case then I think we don't need quickOpenPreviews unless users ask for it.