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 #6424, #4963).

[osiewicz]

Hey, thanks for a PR! we already have a setting section for tabs (see e.g https://github.com/zed-industries/zed/pull/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:

• https://github.com/zed-industries/zed/pull/2742

Specifically, @maxbrunsfeld's comment:

• https://github.com/zed-industries/zed/pull/2742#issuecomment-1640663137

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: https://github.com/zed-industries/zed/issues/7653

[wmstack]

Also worthwhile to have a "merge" placement where the title bar is merged with the tab bar https://github.com/zed-industries/zed/issues/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 https://github.com/zed-industries/zed/issues/7653 to be implemented. And the tab switcher is pretty close, it's waiting for a couple https://github.com/zed-industries/zed/pull/8782 of other https://github.com/zed-industries/zed/pull/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 https://github.com/zed-industries/zed/pull/7356#issuecomment-1995101391, 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.

[alygin]

Given that Zed now has Tab Switcher, what other prerequisites must be met so we could allow the user to hide tabs?

[maxdeviant]

In https://github.com/zed-industries/zed/pull/10240 we added a new tab_bar field to the settings.

Can we put these settings under that instead of under tabs?

[alygin]

@maxdeviant, thanks for the info! Done.

[baldwindavid]

I'm looking forward to stop seeing tabs. 😃 @alygin , really nice work on all of this and the PRs that blocked it.

[wmstack]

It is great work, though again, I hope that the tabs might be moved to the title-bar in the future. This is because the title-bar is always there and is mostly empty anyway.

[alygin]

It is great work, though again, I hope that the tabs might be moved to the title-bar in the future. This is because the title-bar is always there and is mostly empty anyway.

@wmstack, thanks. While I like the idea of occupying empty space with something useful, like moving tabs to the title bar, I think there're some design issues yet to be solved.

For instance, let's assume we have tabs in the title bar. The user splits the window into three panes and the currently active pane is the bottom right. Tabs will look confusing in this configuration. They'll look like relating to the top pane.

Even just splitting the window into two panes vertically and switching to the right pane will leave us with tabs over the left pane while we're working with the right one.

Do you know editors that solve this problem in a good way?

[pepehandsjpg]

I'm looking forward to stop seeing tabs too. Great work! Is there anything blocking this MR from being merged?

[alygin]

@mikayla-maki, do you think something like Open Editors in VS Code or Open Files in Sublime Text will work?

A toggable view in the Project Panel. In Zed it could be something like this:

[mikayla-maki]

@alygin I think that could work too. We’d need to get a once over from @iamnbutler for such a large addition to our UI.

[wmstack]

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

[iamnbutler]

Sorry I haven't been around to catch up on this thread. It is pretty unlikely we would consider shipping tabs in the title bar without a really compelling solution to it's issues.

The above screenshot does not reach that bar, and the reason we didn't ship it in the first place is 1) it doesn't mesh well with splits and 2) the titlebar is important real estate foe collaboration, which is a primary concern for us.

I'm not opposed to exploring an option for hiding tabs, or some sort of collapse UI, that works for tabs in the title bar, but just moving the tabs up there is unlikely to be a solution we ship in my opinion.

As for bottom tabs... I'd like to see some examples of this and proof this is something that a large number of people want before we consider adding it.

As for open editors or open files, I think we could do something like this, but I would want to explore the UI further. It doesn't feel very much like native Zed UI.

[alygin]

> As for bottom tabs... I'd like to see some examples of this and proof this is something that a large number of people want before we consider adding it.

IntelliJ products support bottom tabs placement:

As far as I know, other editors only support it via extensions or various hacks. But I don't know how often it's used. I personally preferred it for some time to the top placement, but that's obviously doesn't make statistics :)

My main intention in this PR is to have the no-tabs mode, while the bottom placement is just a (relatively) low cost addition. I can drop it with no regret.

As for open editors or open files, I think we could do something like this, but I would want to explore the UI further. It doesn't feel very much like native Zed UI.

BTW, the UI looks lighter in case of a single editor pane (which is usually the case in the tabless mode):

[baldwindavid]

@iamnbutler

As for bottom tabs... I'd like to see some examples of this and proof this is something that a large number of people want before we consider adding it.

I can't speak for a large number of people, but would note that I place tabs at the bottom of iTerm (which are a different type of tabs than Zed) which feels more out of the way. That being said, as @alygin mentions, the main goal is an option to remove tabs, so perhaps best to limit the scope to that for this PR.

I'm not opposed to exploring an option for hiding tabs, or some sort of collapse UI, that works for tabs in the title bar, but just moving the tabs up there is unlikely to be a solution we ship in my opinion.

I am a longtime vim user and use vim mode in Zed. I see the ability to hide tabs as an important step towards vim parity. A "Zed tab" is like a "vim buffer", and you would not see a vim buffer displayed as a tab. You wouldn't see it at all except via keyboard access, which @alygin so kindly implemented in #7653. Confusingly, vim does have things called "tabs" but they are a completely different beast with no current corollary in Zed; closest would probably be the project switcher (which is not really close at all). Anyway, I'd not want to see the Zed tabs, including any sort of "collapsed" or sidebar widget.

Again, I can't speak for others, but my perception is that the vast majority of want for this feature would be keyboard-driven because that's how vim, and other modal editors like Helix, work. I generally understand the principle of supporting mouse-driven workflows, but think it goes a bit far here. The tab_bar.placement setting is already an enum which supports the ability to do mouse-driven workflow with "top" or "bottom". Perhaps there could be other options for "collapsed" and/or "sidebar", but then I'm going to want an option to hide those too. And, if in order to do so, there has to be a way to do it mouse-driven, we enter an infinitely recursive situation.

Anyway, my two cents is that it's okay to provide an option to show or hide the tab bar and if you need a way to access tabs via mouse, probably I would suggest not hiding them :)

[williamdes]

About the tab bar, if anyone wants to do feature request about the tab bar: https://github.com/zed-industries/zed/issues/5005 Wrapping tabs would be great!

Again, I can't speak for others, but my perception is that the vast majority of want for this feature would be keyboard-driven because that's how vim, and other modal editors like Helix, work.

I prefer my tabs up, because all software has them up. So my window manager bar is up. And all the clicks are to be done up. No need to go from up to down between an editor and the browser for example.

[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

[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.