Oni: Default neovim tabs behaving weirdly

[Bretley]

I'm not entirely sure what's wrong here but doing :tabnew then :tabprev hides the newly created tab... I'm going to try and hunt down some init.vim fixes

[jordwalke]

I believe I’ve created an issue for this. Away from keyboard at the moment. Oni encourages use of buffers but I agree it would be nice if this tabs bug was fixed. I’m a heavy tabs user, so it’s currently blocking my use case. I’m not clear what the benefit of being buffer centric is. The downside of tabs is that it makes it harder to implement docked panels - but Oni implements those itself anyways so I don’t know what the remaining trade offs are.

[CrossR]

I’m not clear what the benefit of being buffer centric is.

To me at least, I find being buffer centric more new user-friendly, in most cases.
There were times when I'd open vim file1 file2 file3 and then be confused where the 3 files had gone, and more confused when I tried to exit and it complained that I had more files to edit.

Being buffer centric means that situation, and any plugins etc that mess and open up buffers, or new users that open up buffers accidentaly etc, can more easily swap back.

I might be biased since I took forever to get my head around the concepts of buffers.

That said... setting tabs.mode to "tabs", should swap back to the Vim style tabs in Oni UI. ("native" gives the native Vim tabs and Vim tab UI if needed and there is an issue).

[bryphe]

Thanks @Bretley for logging the issue!

I'm not entirely sure what's wrong here but doing :tabnew then :tabprev hides the newly created tab... I'm going to try and hunt down some init.vim fixes

For this particular issue, as @CrossR mentioned, should work correctly with 'tabs.mode': 'tabs'. At least it seemed to work OK for me:

Let me know if you're doing / seeing something different, @Bretley !

I’m not clear what the benefit of being buffer centric is.

Yes, @CrossR described this well - buffers-per-tab is a similiar model to other editors like VSCode/Atom/Sublime. They don't really have a concept that maps to 'vim tabs'. IMO, 'tabs' in Vim are somewhat poorly named... they should be 'window layouts' or something (at least from my perspective)
😄

We had a few discussions in the past around this, some of these conversations may be relevant:

• #593
• #586
• #949
• Also a bit in the PR here #922

This does keep coming up though as a blocker for vim use cases, and because people have voiced it as a consistent blocker, I've started to backpedal a bit and wonder if we could get the best of both worlds:

• By default, file-per-tab - meaning if I open via 'Open File' or 'Quick Open', it by default opens in a new tab (probably using :tab drop so if the file is already open, we go to that tab).
• Files passed in the command line always get opened in a new tab (Kind of like the vim -p command).
• If the tab name looks like a file (has an extension), we'll show an icon for it as we do for buffers
• If _any buffer_ associated with the tab is dirty, we'll show the dirty icon

To a novice user coming from Atom, Sublime, VSCode - I _think_ the behavior would be pretty similiar. It's only once they start getting into splitting / rename tabs / etc that it might get more interesting. For an experienced Vim user, they'd have a nice experience for tabs out of the box, and also get the benefit of seeing the list of buffers in our sidebar (eventually):

(2 tabs, 3 buffers - tabs.mode is 'tabs' - note that you see the 3 buffers in the 'opened buffers'. And if we implement #1173 , there are lots of options for navigating your workspace!)

I've heard the feedback that the buffer-by-default approach isn't ideal.... perhaps it's worth pivoting and trying the above out? If we can satisfy both the novice user + experienced user scenarios, that'd be awesome. Let me know what you think.

I’m a heavy tabs user, so it’s currently blocking my use case. I’m not clear what the benefit of being buffer centric is.

Oh and @jordwalke I poked around looking for this in our issues - do you have more info on the blocker you're hitting? Is the same :tabprev/:tabnext issue, or something different? Definitely want to make sure we address it!

[akinsho]

This might very well be a tabs v. spaces sort of comment but I think if oni is to appeal to longterm vim users a tabs first approach would be I think/ would imagine unpopular (not quoting numbers just an opinion), tabs as far as the vim docs are concerned are for layouts, I think it'll be a hard one for oni because it's a point where vim is just different, I think ideally people should choose tabs or buffers though in terms of introducing people to vim it's a point where you might be making things easier in the short term by not introducing buffers only to lead to poorer longterm understanding of vim, although I'm not sure tabs are any easier to grasp than buffers.

[TalAmuyal]

@Akin909, I agree.

I would like to add that personally, I prefer splitting vertically and horizontally, rather than using tabs.
I would like to use tabs as workspaces: Each tab has splits that are related to each other (for example the same project).

So when working on Oni, Oni's splits would be on one tab, and oni-api's splits on another.

[CrossR]

I'll close this out since we swapped to tabs as default now, as well as not being able to repro this in the latest version of master.