Completely disable editor tabbing behaviors

[agausmann]

(I am filing this as a feature request and not a bug report, because I don't want to assume that it is incorrect or unexpected behavior. I am just trying to explain why the existing options for hiding tabs don't work for me. I leave it up to the maintainers to decide whether the existing behavior is reasonable, and whether this should replace the existing behavior of showTabs: false or be a new setting.)

Background

As of VS Code 1.80.1, when you set "workbench.editor.showTabs": false. it seems that it only hides the tab bar, and most of the UI still behaves as if there are tabs. For example:

1. If you close the "current tab" (e.g. Ctrl+W or middle-clicking the tab bar that now shows a single tab), then it picks one of the other recently-opened files to display.

2. If you make changes to a file without saving, and then open another file in the same pane, the changes don't seem to be saved immediately. In this state, if you try to close the workspace or open another workspace, a dialog will pop up asking if you want to save the changes to the file that was previously open.

3. If you toggle "workbench.editor.showTabs" between false and true, the tabs are preserved, and will also include any files opened while it was set to false.

All of these behaviors seem to imply that VS Code still uses tabs in the backend, but only shows the user one tab in each pane. This is not a great experience.

Personally, I want to disable tabs to try to improve focus / reduce visual clutter. However, if the tabs are just hidden, it actually makes things worse because all the mess is still there but invisible. While using this setting, I often accidentally leave unsaved changes in the background, which affects every other operation that may depend on the changes in that file (compiling, running, version control, and other command-line interactions).

Proposal

As the title describes, I would like a mode that completely disables tab functionality. In particular:

• When the user closes a "tab" with tabs disabled, treat it as if their intent is to close the entire pane. There should be no tabs open in the background to take focus, because there should be no tabs.

• Nothing should ever be left open and unsaved in the background. If the user tries to open another file in a pane where the current file has unsaved changes, then immediately prompt them to save/discard/cancel.

[bpasero]

Part of it could be achieved by mapping workbench.action.closeEditorsInGroup to Ctrl/Cmd+W if you use keyboard.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[agausmann]

👎 I wish Code treated feature requests more like a community forum instead of a personal to-do list.

Let me offer you a different way of thinking about issues ... A space for the community to work, rather than an action item for you to deal with personally ... It does not matter if this process takes days or weeks or years to complete.

The core developers don't need to be responsible for implementing every feature, but this system just places the focus even more on them, and it rejects feature requests based on a stochastic popularity contest instead of genuine merit or reasonableness.

I simply want a very specific feature to improve my own user experience, and I am willing to develop it myself. But I haven't been given any indication whether this feature would even have a chance of being accepted.

The least I can ask is for you to read and understand the issue and give an indication of understanding. It would be a trivial amount of effort to do a basic evaluation of the merit of the request, like "this sounds nice" or "I'm not sure how I feel about that". I don't even care if it takes you years to get through the backlog to me. I opened this issue to have a human conversation on the merits (even a brief one), not to be rejected for being the only voice.

Part of it could be achieved by mapping workbench.action.closeEditorsInGroup to Ctrl/Cmd+W if you use keyboard.

I'm not looking for band-aid solutions. I'm not just a user, I'm a developer who is willing to become a new contributor! How do you handle that?

[gjsjohnmurray]

Can the settings described in the test plan #89275 form a basis for meeting your need? Based on a quick reading and no experimentation you would want an additional setting that made the limit (which you would set to 1) also apply to dirty editors, right?

[gjsjohnmurray]

Effectively a variant of the setting that was added subsequently, see #144309 (comment)

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[agausmann]

Can the settings described in the test plan #89275 form a basis for meeting your need?

Yes, that gets very close. I've tried toggling workbench.editor.limit.excludeDirty and it doesn't seem to make a difference; dirty editors are always left open.