Editor tab bar settings

[alygin]

This PR is another step to tabless editing (#6424, #4963). It adds support for tab bar settings that allow the user to change its placement or to hide completely.

Configuraton:

"tab_bar": {
  "show": true
}

Placemnet options are "top", "bottom" and "no".

This PR intentionally doesn't affect tab bars of other panes (Terminal for instance) to keep code changes small. I guess we'll do the rest in separate PRs.

Release Notes:

• Added support for configuring the editor tab bar (part of [Feature] Tabless editing #6424, Hide certain visual elements #4963).

[osiewicz]

Hey, thanks for a PR! we already have a setting section for tabs (see e.g #2739); I think your change would fit in better in that.

[alygin]

Hey, thanks for a PR! we already have a setting section for tabs (see e.g #2739); I think your change would fit in better in that.

Oh, thank you for pointing out! I somehow missed that. I'll move the placement setting to the existing tabs.

[JosephTLyons]

Hey @alygin, we actually had a PR open for this at one time, but it was blocked because the team wanted to ensure that the user had an alternative way to check on the state of their buffers when tabs are hidden. I'm not sure where everyone stands at the moment, but here is the PR with the additional info:

• feat(workspace): allow hiding tab bar #2742

Specifically, @maxbrunsfeld's comment:

• feat(workspace): allow hiding tab bar #2742 (comment)

I'll let Max / the other devs chime in with their current thoughts on this.

[alygin]

@JosephTLyons, thank you for pointing to the existing discussion on the subject! Unfortunately, I didn't see it before.

I'll get back with my ideas / changes later.

[alygin]

Filed a feature request: #7653

[wmstack]

Also worthwhile to have a "merge" placement where the title bar is merged with the tab bar #5066 to reduce the editor footprint.

This can be done in VSCode with the help of APC Customize UI++ but is quite buggy and affects the draggability of the title-bar, difficulty in aligning the traffic light buttons and forces you to use "native" windows on VSCode. This means the context menu has to be native instead of custom.

[ConradIrwin]

@alygin are you still planning to work on this one? If not, I will close to tidy up our PR queue.

[alygin]

@ConradIrwin, yes, I'm absolutely committed to this task. This PR is waiting for the TabSwitcher to be implemented. And the tab switcher is pretty close, it's waiting for a couple of other PR's to be merged.

I started all this TabSwitcher thing just to be able to merge this PR and hide the tab bar :)

Though you can close it if it's a burden to keep it in the queue. I'll reopen as soon as all the prerequisites are ready.

[ConradIrwin]

Sounds good! Happy to work with you on any of this (there are some slots at https://calendly.com/conradirwin/pairint, but if none work for you let me know ***@***.***) conrad

…

On Wed, Mar 13, 2024 at 11:31 AM, Andrew Lygin ***@***.***> wrote: @ConradIrwin <https://github.com/ConradIrwin>, yes, I'm absolutely committed to this task. This PR is waiting for the TapSwitcher <#7653> to be implemented. And the tab switcher is pretty close, it's waiting for a couple <#8782> of other <#9099> PR's to be merged. I started all this TabSwitcher thing just to be able to merge this PR and be able to hide the tab bar :) Though you can close it if it's a burden to keep it in the queue. I'll reopen as soon as all the prerequisites are ready. — Reply to this email directly, view it on GitHub <#7356 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXAQHHLDJPNYT5WFZUF43YYCEPFAVCNFSM6AAAAABCYZKQD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJVGEYDCMZZGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alygin]

Sounds good! Happy to work with you on any of this (there are some slots)

Thanks! I've booked a slot.

[baldwindavid]

@williamdes To be clear, that comment of mine you quoted was regarding hiding tabs completely. Whether an option for tabs at the bottom is provided is not something that matters to me. But for vim and other modal editors tabs are not expected to be displayed at all.

@alygin I've been using this PR daily and hiding tabs. It works great mixed with the tab switcher.

This PR intentionally doesn't affect tab bars of other panes (Terminal for instance) to keep code changes small. I guess we'll do the rest in separate PRs.

I see this note. I'm not so sure I'd even hide tabs in the terminal just because I typically have a very limited set that I don't mind seeing. Not that they shouldn't be hideable eventually, but it doesn't look surprising to me. The only thing that took me a bit by surprise was that the tabs display in a project search. That might be a good fast follow if this eventually gets in.

[0x2CA]

Well @alygin for your questions, I had some different considerations. But first in your diagram above I think that the title-bar should resemble the concept image in #5066, namely, the tabs should be vertically centred without any margin and unfocused tabs should have the same colour as the title-bar.

The idea that I was initially considering was

1. When there is a vertical split, it would be a split of the tabs in the title-bar as well, just as if it were a tab bar that is split.
2. For horizontal splits or splits that are not supposed to be on the title-bar there could be a new tab-bar separate from the title-bar, just like if the tabs are not hidden.

In essence this would be like VSCode with APC Customize UI++ where you hide the title-bar.

However, I do have another suggestion, which is inspired by Vivaldi tiles, all the tabs are in the title-bar to the left, and then when you click on them, the focus moves to the different panes

Vivaldi Relevant Video Tab Tiling Vivaldi Article

It seems to me that tab-tiling doesn't have a way to deal with the same buffer, but in vim-bufferline tabs are just visualizations of the buffer, and the user doesn't really care what's open, just what they're currently editing, or what they want to change the current display to.

For multi-window users who just need to choose the layout, what to display in different windows, and then write or review

Hidden tabs paired with a buffer switcher is an alternative to this functionality, though lacking the possibility of mouse manipulation

vim: when splitting window, buffers shouldn't be split, each split window can access any opened buffer. #8013

out of date

[mikayla-maki]

Given the discussion here, and our designer's skepticism, I'm revising my review:

This PR is great as is, let's remove the 'bottom' placement for tabs until we have more data, and then we can merge this :)

Thanks for all the hard work on this one @alygin, I know it's been a long road!

[alygin]

@mikayla-maki, since we're removing the bottom option, shouldn't we make this setting a simple boolean flag, like show: true?

[alygin]

The only thing that took me a bit by surprise was that the tabs display in a project search.

@baldwindavid, fixed

[mikayla-maki]

shouldn't we make this setting a simple boolean flag, like show: true

Let's do that. Generally, I like to prefer enums to booleans. But also, the phrasing of placement: none is a little awkward. show: true tells the story well.

[alygin]

Let's do that. Generally, I like to prefer enums to booleans. But also, the phrasing of placement: none is a little awkward. show: true tells the story well.

Done

[iamnbutler]

Thanks – that settings change brings it more in line with other similar settings.

[mikayla-maki]

Thank you!

[hedefalk]

Yey! I've been waiting for this!

[Moshyfawn]

Closes #11727

[d1y]

A great option, closer to zen mode, but can you add a command?
Is it like editor:: ToggleTabbarShow ?
@alygin

[alygin]

can you add a command? Is it like editor:: ToggleTabbarShow ?

@d1y, while adding such a command is technically a simple task, I'm not sure if it can be naturally embedded into the existing UX-patterns.

The state of toggable-by-action elements is stored in the local DB and it may conflict with what settings.json contains. For instance, I may have tab_bar.show=true in the settings.json and then hide it via the toggle-action. What should we do in this case on start? Or what if I have tab bar hidden via the toggle-action and via tab_bar.show=false, but then change settings to tab_bar.show=true? If we show the tab, it contradicts the toggle-state, if we don't, it confuses the user because the setting change has no effect. Etc.

Do you know other features in Zed that have both the setting in settings.json and a corresponding toggle-action?

[ConradIrwin]

Vim has both. The toggle command writes to the settings.

[alygin]

@ConradIrwin, will it be OK if Zed behaves the same way?

[baldwindavid]

@alygin Just in case it's not clear, the actual workspace::ToggleVimMode command writes to the settings. As does theme_selector::Toggle, though with an additional step.