[Feature Request] Modern tab management option

[nwaywood]

One thing I always wished about vim is that I wanted buffers to work the same way they do in every other editor (called tabs in other editors). I never thought it was possible but I saw this tweet thread on the weekend by @jordwalke that got me really excited thinking about having this in Oni.

Tweet thread: https://twitter.com/jordwalke/status/965030611458056193

In the thread, he talks how he is using wintabs (I realise Oni probably wouldn't actually use wintabs under the hood, just linking it here as an example).

In summary, I think it would be awesome if Oni had an option to make tabs work like normal tabs. Buffer tabs is similar but is not quite as intuitive.

[badosu]

@nwaywood Can you describe what you mean by 'normal' tabs?

[TalAmuyal]

If I understand correctly, @nwaywood means that he wants the tabs to be per-split. That means that if I split my window, I will have two tab-bars and a further split will create yet another tab-bar.

@nwaywood, is that what you mean?

[badosu]

This seems like a nice use case to support, if done perhaps a new tabs.mode?

[nwaywood]

Yes basically what @TalAmuyal said. By "normal" tabs I mean the way tabs work in Atom VSCode etc.

So tabs will be per-split, but also when you close a window/split the corresponding tab for the buffer that was in that split will also disappear. For example:

1. Open a new buffer in a new window/split
2. Close that window
3. With vim buffer tabs, the tab for that new buffer will still be there. With "normal" tabs it would now be gone

@badosu Yes I was thinking something like tabs.mode: "modern"

[jordwalke]

There's a few ways to create a modern tabs experience. I have gotten used to the VSCode/Atom mode where each split can have multiple tabs. I think you could also accomplish a "modern" experience where tabs themselves contain splits, as long as all the plugins were diligent about jumping to existing buffers and as long as a couple of other details were done well. But maybe now, people are just getting used to the VSCode/Atom/Sublime paradigm whether or not it is superior.

[hoschi]

What is the benefit of the "modern" tabs-in-splits model vs the vim splits-in-tabs model? (This is not a rethorical question, I would love to here some pros/cons)

My view at this is that splits-in-tabs give me containers to put different buffers into and arrange/size them the way I need it. A tab is a container aka workspace or view. You can put content which belongs together in a workspace, like:

• code + test
• html + css
• model + controller + view
• code + documentation
• interface + class + sub class
• code + helper
• ...

You use different workspaces for all the different parts you work on:

• general component
• feature files
• search results
• backend API
• DB model definition
• README.md
• mock server fixtures
• ...

With tabs-in-splits, how do you switch from your current code+test+doc files to your search results or server-api+db-model+fixtures? You need to go into each split and select the corresponding tabs, which are three steps for one "action". With splits-in-tabs, well, you just go to other tab, which is truly one action.

And this isn't even considering buffers, till now you can use files as you would use them in every other editor which doesn't have buffers. No additional learing process so far. With buffers though, splits-in-tabs become even more natural, because you now can have different workspaces which show you parts of other workspaces.

The user can decide how deep he would learn these things. This depends of how much problems he has achiving the things he wants. You can even use buffer per tabs view, which I use through ctrlspace, to better organize your workspaces.

I subscribed how splits-in-tabs can be used as containers, does someone have other usages I'm not aware of? What is the idea behind tabs-in-splits? They can't be used as containers for the current visible space, they contain only files and give them a dedicated size. This means for me I group files by content size? At least I have no use case for this in my daily workflow, would love to hear workflows from others which fit that idea!

Question with answer, from thread OP mentioned, why tabs-in-split makes sense:

• because user wants to have a docked file viewer
• Oni has this now and it show that you still can use normal splits-in-abs
• As an aside: I don't understand what questions a docked file viewer answers either. I don't stare at my current open file and ask my self "where are all the other files located?". If I want to open another file I open the fuzzy finder and just type the name of the file.

Also, other people like the vim tabs mode more than that from Atom

[badosu]

@hoschi While I agree with many of your arguments, I see that oni focuses on bringing modal editing with vim to broader audiences, not exactly to just be a good frontend for already established vim users (even though that's why I use it).

With this in mind it makes sense to provide this option, I would not like it to be default on my computer, but I can see having the option may make it easier to target these audiences.

[hoschi]

I see the audience argument. Copying not useful "features" from other editors brings vim-beginners not really further, does it? There was no argument in the initial request of implementing tabs-in-splits, beside "all other use it".

To reach a broader audience Oni has the buffer tabs mode which make the editor behave like a browser or a file explorer. This is a really great way to onboard people which are new to editors in general. On the other side we have the vim tabs mode which can be "learned" how deep a user wants to go, as described already. Oni has added a whole menu to use it, if you don't want to learn the keyboard short cuts for it.

Adding yet another mode in between these two already existing ones is pointless to me. At least without any arguments for it.

[bryphe]

Thanks for creating the issue, @nwaywood !

I'm a bit late to the party here but I appreciate the discussion and thinking here! Was cool to read through @jordwalke 's twitter thread, makes a lot of sense to me. This actually is something I have been experimenting with for a while. From my personal experience (which is coming from Visual Studio back in the day, then Atom/Sublime/VSCode), the 'tabs-in-split' metaphor is natural to me.

I've been working on functionality which moves towards this behavior - looks like this: It's built on 'multiplexing' Neovim processes, but that's really an implementation detail...

In the screenshot, there are three 'Oni-managed' vertical splits, each containing it's own tab line. This doesn't preclude splitting them via Vim - each 'Oni-managed' split is just a Neovim instance, like if you used tmux to split Neovim. On the first vertical split on the left, I introduced a vim horizontal split.

The nice thing about Neovim is that we can actually persist marks, yanks, etc between these splits using wshada and rshada on focus enter / focus leave. So the fact that it's multiplexed is relatively transparent to the user (means extra work for Oni to implement stuff like session persistence though).

The reason I'm pursuing this is that, along with the arguments for tabs-in-splits being more familiar to devs coming from Atom etc, we can actually provide a better UX in oni-managed splits. Note that you can see the scrollbar in all the splits in the screenshot, except for the vim split. We can't reliably get all the window information for inactive windows today, so some of our UX capabilities are crippled today - it's the same reason we only show scrollbar / diagnostics in the active window.

My plan at the moment is to have two configuration settings:

• editor.split.mode - 'oni' | 'native'. If set to oni, we'll use the oni-managed splits (tabs-in-split).
• tabs.mode - this is the existing setting today, which is either 'buffers' | 'tabs' | 'native'

These settings are actually orthogonal, because you can have 'tabs-in-split' functionality for any value of tabs.mode`.

Note that this is sort of available in the master build today - you can run the following line in the developer tools to try it out (make sure to set editor.split.mode to 'oni' in your config first):

Oni.editors.activeEditor.openFile("test2.ts", "horizontal"); Oni.editors.activeEditor.openFile("test3.ts", "horizontal");

Lots of bugs still but I'm stoked that we're getting close to supporting this...

[nwaywood]

@bryphe Thats looking great!

One thing I want to mention though, not sure if it'll be possible but want to throw it out there just in case...

In my head originally was that we could have a tabs-in-splits implementation as a direct replacement for vim buffers and windows and NOT a replacement for vim tabs. My reasoning for this is that I do like the idea of having workspaces and I use them as well. In Atom I use https://atom.io/packages/atom-vim-like-tab which gives vim tabs in atom IN ADDITION to tabs-in-splits (UI wise I think we could make it look a lot nicer than in atom-vim-like-tab).

Imo this is the best of boths worlds, you get vim tabs/workspaces and within each workspace you get tabs-in-splits.

What do you think @bryphe ? Do you like that idea? Is that possible to do with Oni?

[Melkor333]

As you can see I opened the issue #2424 to have a better tabs-buffers overview. But with the "oni-splits" this probably becomes obsolete (since one tab=one file) - especially when implementing the tabs-in-splits-in-workspaces as proposed by @nwaywood.

So I guess if @bryphe likes the tabs-in-splits-in-workspaces idea I could close my issue as duplicate. Otherwise my issue would probably be easier to implement than this one and may work for a cheap alternative...

Additionally I would really like to work on this - but since I'm a js beginner this is probably too complex for me? :smile: