Closing tabs from command-line (ex) mode

[keforbes]

If I have multiple tabs open and I type :q or :close, the focus will change to a previous tab as if the active tab had closed but the tab itself still remains. gt will correctly skip the "closed" tab but clicking on the tab will still display the file. It seems the only way to close a tab is by clicking the X button... with your mouse. 😱

[bryphe]

It seems the only way to close a tab is by clicking the X button... with your mouse.

Yikes, that is atrocious!

I think this is related to #593 - by default we just show the buffers , unless editor.showVimTabs is set to true. If you change that setting, I think the behavior will be more what you would expect.

My goal with showing buffers by default is it more closely maps to how other editors work, but it sounds like this default is really confusing to both you and @bert88sta who have a tab-based workflow, and expect the tabs in Oni to map to Vim tabs.

So a couple questions:

• Does setting editor.showVimTabs to true give you the behavior you'd expect?
• Would you prefer to have the default changed? I know @bert88sta would prefer that 😄

[bryphe]

One thing I realized too, if we change that default to editor.showVimTabs to true, it kind of fixes #591 too...

[keforbes]

Setting editor.showVimTabs to true didn't appear to have any effect on this. Also, even if this could've been handled by a config setting I'd still call it a defect since gt iterates through all tabs and :q causes gt to skip the tab but the tab is actually still visible. Even if you're trying to distinguish between buffers and tabs I think we're still mixing metaphors here.

[CrossR]

I think this is the bug that I bump into the most when using Oni.
Its not an actual issue that stops me working, but I will just have tabs that are left behind.

A few other related issues (or at least issues where tabs fall behind where they should be) is using Save As is not reflected in the tab line until you swap back and forth to a different tab. Similarly if I open multiple tabs (with :e test1 then :e test2) it will stay on the first tab until I enter insert mode and then it jumps over.

These all feel somewhat related, but I can't be sure.

Is there anything that makes sense to look into for this?

[bryphe]

@CrossR - Just curious, do you use 'tabs.mode':'tabs' or 'buffers'? There are a couple of different entry points for each.

A few other related issues (or at least issues where tabs fall behind where they should be) is using Save As is not reflected in the tab line until you swap back and forth to a different tab.

I think @Akin909 had looked into this for an investigation, and IIRC he mentioned there were some oddities in the timing of getting the buffer events back.

Similarly if I open multiple tabs (with :e test1 then :e test2) it will stay on the first tab until I enter insert mode and then it jumps over.

This one seems to work better for me in tabs mode vs buffer mode. In tabs mode, we rely on Neovim to send us the events (since we have the externalized tabline) - it's the tabline-update event we get from NeovimInstance. That's then handled here:

oni/browser/src/Editor/NeovimEditor/NeovimEditor.tsx

Line 421 in ab0704a

this._neovimInstance.on("tabline-update", (currentTabId: number, tabs: any[]) => {

In buffer mode, we listen to a variety of events and try and populate the buffer list after those events - some examples here:

oni/browser/src/Editor/NeovimEditor/NeovimEditor.tsx

Line 864 in ab0704a

this._bufferManager.populateBufferList(evt)

oni/browser/src/Editor/NeovimEditor/NeovimEditor.tsx

Line 907 in ab0704a

this._bufferManager.populateBufferList(evt)

It's possible that we're missing an event, potentially -

[CrossR]

Just curious, do you use 'tabs.mode':'tabs' or 'buffers'? There are a couple of different entry points for each.

I use buffers mode, since I'm still pretty useless with buffers so having them all shown on the tabline is great for me.

It does seem like a timing issue and I couldn't remember where the discussion about this had gone on. I'll try and have a look at some point and see if there is any other event we could hook into.

It would make sense, since we get updates on buf enter and unload, they may not capture a new buffer and a buffer write. Then when starting editing and swapping away and back, the buf enter autocmd is being kicked off, at which point we do capture it. Perhaps linking up the BufNew or BufWrite would fix these issues, but there could be additional issues if we are creating a lot of new autocmds.

[akinsho]

@CrossR yeah its been a bug bear of mine specifically renaming buffers etc. and we've had to resort to a bufferDelete command that navigates back and forth just to hit a bufEnter event we discussed this is #1334 which is where populateBufferList came from the name for the post save event is I think fileReadPre its in the vim docs on autocommands somewhere. I worked on it a little and managed to get the title to update by hooking into the event the issue was that the buffer lost its highlighted status for some unknown reason which seemed like an annoying result so I havent done much more with it

EDIT: Re. vim events I've read through autocommands docs more than I could ever have wanted/or dreamed and seems there are loads we are not responding to, not that we need to respond to all but definitely there are a few that we definitely should be but what not clear is how or which exactly (till a bug creeps up)

[CrossR]

I'm pretty sure this is fixed for me now we've swapped to tabs by default, or at least I've never hit it since.

Does anyone who uses buffers still encounter this? I seem to think @Akin909 uses buffers mode.