Allow to hide editor title section entirely (tabs, breadcrumbs)

[robamler]

Implement a popular request to make better use of vertical screen space.

Fixes #33607

Currently, when hiding editor tabs with the action "View: Toggle Tab Visibility", tabs are not really hidden but rather replaced with a display panel that seems to have strictly less functionality than tabs. This commit changes the behavior [edit: adds a new option] so that tabs are really hidden and the editor gets more vertical screen space. This has been a popular request (issue #33607).

I may be missing some rationale behind the current behavior. If that's the case then we may be better off introducing an additional configuration option that lets users define the behavior for hiding tabs. However, I'm not sure how to phrase such an option because I don't understand the motivation behind the current behavior.
[edit: the proposed new behavior is now behind a new configuration option "Workbench > Editor: Show Title Bar" that is independent of tab/breadcrumb visibility]

• Current layout with tabs (this remains unchanged by the proposed commit):
  

• Current layout when tabs are hidden [edit: now also unchanged by the new proposal]:
  

• Proposed new layout when tabs are hidden [edit: when "Workbench > Editor: Show Title Bar" is set to false] as implemented in this commit:
  

[msftclas]

All CLA requirements met.

[robamler]

I think the failing checks are unrelated to this commit. Is this a common occurrence?

[robamler]

Would anyone like to give feedback on this? I'd be happy to make modifications if the proposed change in behavior is deemed too invasive. I'd just like to fix #33607, and it seems like this PR (with modifications if requested) could do that quite easily.

[suo]

Any update on this? This is very nice from people used to vim @bpasero.

[bpasero]

A few comments after playing around:

• this cannot be controlled by the existing workbench.editor.showTabs setting, otherwise we break the behaviour for all users today that have tabs disabled but still want the editor title area with title and actions
• we since added breadcrumbs. should we have a way to still show breadcrumbs but not title or neither?
• when running in this mode you loose access to the editor actions as well as the editor actions overflow toolbar (...). do we need a different way then to access these?
• I see that tabs get hidden simply via CSS rule but there may be more places where we compute the editor height assuming there is a static 35px editor title above so we need to account for that

Just throwing this out so that people understand this cannot just be merged in this form without further changes and more UX discussions how we want this experience to be.

[robamler]

Thank you for getting back, @bpasero. I understand from your comment that the current PR is too intrusive. It hides the title bar when hiding tabs, and some users may not want that. I have a proposal for a slightly adjusted implementation that, as far as I can tell, does not remove any functionality from VS code.

It seems like there are two aspects to the UI here, and they interact somewhat unintuitively:

• The "toggle tab visibility" action controls whether or not tabs are shown; and
• the "breadcrumbs: enabled" option controls whether breadcrumbs are shown. However, this option works only if tabs are hidden. If tabs are shown then breadcrumbs are always hidden. [edit: this is possible now]

Apart from being very unintuitive, this coupling between tabs and breadcrumbs also restricts the space of reachable settings. VS code currently allows only two out of the four possible combinations between tabs and breadcrumbs:

	show tabs	hide tabs
show breadcrumbs	not possible [edit: possible now]	possible
hide breadcrumbs	possible	possible, but apparently to no avail †

^† Could someone clarify the use case of the current implementation for hiding both tabs and breadcrumbs? The current implementation still shows a title bar that seems to have strictly less functionality than in any of the other options, while taking up just as much space. Am I missing something here? I understand that the title bar still contains some useful things such as the current file name and buttons for editor actions, but these are also available by showing either tabs or breadcrumbs, without taking up any more space.

My proposal is to change only the setting in the lower right corner of the above table. I.e., if both tabs and breadcrumbs are hidden, then the title bar would disappear entirely. This would not remove any functionality from VS code because the current implementation for this scenario seems to be useless anyway unless I'm mistaken.

Ideally, the upper left corner of the above table should also be possible (i.e., showing both tabs and breadcrumbs in a larger title bar). But this may be a separate issue. [edit: obsolete]

Any comments on this proposed change? I'd be happy to implement it if it has a chance of getting approved.

[bpasero]

This would not remove any functionality from VS code because the current implementation for this scenario seems to be useless anyway unless I'm mistaken.

You are mistaken, I (and many in the team actually) am using no-tabs, no-breadcrumbs since 7 years (yes, even before VSCode came out) and it is my preferred model. I see all editor actions to the right and I see the editor title to the left.

Even with breadcrumb enabled, they nicely integrate into the no-tabs solution by being on the same line:

[robamler]

Sorry, I didn't mean to step on anyone's toes. Would it be better to introduce an additional "toggle title bar visibility" action that just hides or shows the entire title bar, no matter its content? This way, none of the current appearances have to change.

[bpasero]

@robamler yeah that was my initial suggestion, have a setting that does not refer to tabs (but maybe editor title) so that it can be hidden.

[robamler]

@bpasero I implemented your suggestion. I think this approach is minimally intrusive. Nothing changes unless the user either goes into the settings and changes the new setting "Workbench > Editor: Show Title Bar", or executes the new action "View: Toggle Editor Title Bar Visibility".

I'd appreciate any feedback.

[chrismccord]

I have been driving Robert's PR for over a month now, as the tab/title situation was the main blocker for me fully adopting vscode. It has been working perfectly. I think the suggested title bar setting/toggle is a great solution that will work for everyone. Thanks for the work Robert. I'd love to see this make it in when Benjamin and team have some time to evaluate.

[bpasero]

Thanks, it seems to work nicely. We need to have a UX discussion in the team around this feature and will update here once we decided.

[bpasero]

Here is the outcome of the UX meeting we had today:

• we would like to allow users to choose to hide the editor title but still show the breadcrumb (today title and breadcrumb are living in the same control so hiding the one hides the other)
• we think there should be a way to configure this for zen mode as well (e.g. when entering zen mode, only then hide the title and/or breadcrumbs)
• we need to make sure that all of our built-in editor actions that are present in the editor title are accessible through the global command palette. to give an example: we have actions in the diff editor to jump to the next/previous diff. make sure that these can be accessed alternatively
• we cannot do this check for extensions contributing actions to the editor, so you may end up not being able to fully use extension capabilities in this mode where the editor title is hidden

I do not expect this PR to address these issues. I cannot dedicate time for this PR at the moment but will move it to Backlog where it can be considered in the future.

Thanks for understanding.

[robamler]

Thank you for the update! Too bad this PR didn't make it, but I understand that you can only add a new feature if you can guarantee that it gets all the corner cases right.

Unfortunately, I don't feel qualified to implement the items mentioned by @bpasero above because I don't really understand the motivation behind the tabs/breadcrumbs interaction (see my earlier comment). If anyone wants to continue working on this please don't hesitate to reach out to me if you have any questions about the changes made so far.

[chrismccord]

@bpasero thanks for taking the time to flesh out some ideas around this. I think all the UX meeting points are sound, but I think it tackles a larger and different set of features than this PR. To put another way, I think a feature which merely toggles the tab bar and all its contents is needed by itself. Most of the talks I give involve some amount of live-coding, and this feature as implemented, is essential to that purpose. Breadcrumbs and editor actions remaining visible wouldn't solve the current issue, so while I'm fine with finer grained options laid out by the UX meeting, an all-or-nothing UI toggle remains essential for my workflow and usage. It's sad to see it go on the back-burner for what has been an otherwise amazingly hackable/customizable editor, but I appreciate this made it as far as is it did given your current backlog ❤️

[bpasero]

Closing this PR as we are not convinced this works from a UX perspective.