Move tab functionality

[zerohive]

Move tab functionality

[Futurile]

I appreciate this is WONTFIX, but leaving a comment for other users.

Currently the only tabline plugin that appears to support this functionality is xtabline (https://github.com/mg979/vim-xtabline). It works as discussed by keeping an internal reference. There is a plugin for it if one is using airline. Unlike this plugin or airline (with default tabline) it doesn't support mapping to jump directly to a buffer/tab (e.g. 1-N).

[ap]

I saw. I don’t know if I’ll ever get around to writing one.

I think I don’t want to write a plugin that maintains a list outside of Vim’s own mechanisms, because then I’d have to invent an API, which seems very doubtful that it would be adopted by other plugins (maybe if I were Tim Pope or something… and even then), as well as UI, meaning that users would have to switch from :bnext/:bprev to whatever the plugin provides. It just seems like the mechanism needs to be built into Vim in order to get adopted by users and supported by other plugins.

So I briefly considered using the argument list instead of the buffer list (if the user flips a setting), because that one is built into Vim, and unlike the buffer list, it can be reordered any way you want. The drawback is, you can’t add non-existent files (i.e. new buffers and scratch buffers) to it – all of the entries in the argument list are actual paths by necessity (though the files need not yet exist). So by itself it would be a nonstarter – but I tried to think of some way of working around that which would allow using it for this purpose. So far I got nothing though. (Also, Vim has this weird concept of window-local argument lists. I don’t know of anyone ever using it, but… it’s there, and I have no idea whether I should support it, or if so, how.)

So for now I remain at a loss.

[ap]

Hey there. Glad you enjoy the plugin. 😊

Your sense of how it would be implemented is not at all incorrect. It would indeed just be an array containing buffer numbers. That isn’t the hard part, though. It’s everything that follows from that.

First thing the plugin will need after adding this array is new commands and/or bindings for switching to the next/previous buffer based on that array, to replace :bnext/:bprevious (which are built into Vim and already used by most users of Vim). Next, well, the whole point of doing this in the first place is to let the user move buffers around, so now it needs commands and/or bindings for moving buffers around. And even implementing all of that is not hard. Where it gets hard is:

That’s a lot of non-Vim-standard, this-plugin-only stuff for new users to learn.

Currently the plugin is super easy to adopt. There’s almost nothing you have to do. There’s a few settings you may tweak a bit, some slight differences in what various users prefer, but mostly, you just stick the plugin in your Vim setup and you’re done. (Even so, the documentation runs a couple pages… but users can completely ignore it.)

If I add features to manage the order of buffers, that changes completely. Now the docs run 15 or 20 pages, and many more users will be reading at least some of the docs.

That‘s my dilemma. The programming part is easy… it’s all code you can write while half asleep. It’s the product part that’s difficult.

[ap]

Yes, it would be great if that worked.

The reason it doesn’t is because this plugin doesn’t care about tabs at all, it shows buffers. And you can’t change the order of buffers in Vim.

It would be possible to make this plugin show buffers in an order that’s different from Vim’s own buffer list. To implement that I would have to keep an own buffer list in the plugin. This would require machinery to make sure the plugin’s buffer list stays up to date when buffers are deleted or created. It would also require UI (mostly, new commands) to allow moving buffers around in the plugin’s list. So this is a fairly big feature, possibly as big as the entire plugin already is. But it’s the need for extra UI that’s the worst part, much more than the code complexity.

I would be more inclined to ask the NeoVim people how feasible it is to implement a feature to move or swap buffers in the actual buffer list. (And if they get it done, ask Bram if that feature can be copied in Vim.) That would solve the problem in one place, for all uses of the buffer list. If that doesn’t pan out, I would tend in the direction of a separate plugin which provides the move-things-around layer over the buffer list, that multiple other plugins could then use.

I’m leaving this open for now but I don’t plan to work on it.

[gibfahn]

Opened neovim/neovim#7558

[gibfahn]

@ap so I raised the neovim issue, and it was closed immediately.

Sooks like a separate buffer list in a plugin is the only option.

[ipatch]

Hi 👋, recent Vim / Neovim daily driver here 🚙, and came across this plugin a while back (probably earlier this month) and a convert from using vim-airline. Couldn't help but think vim-airline was getting more bloated by each new update. 🤷‍♂️

I've really been enjoying the snappiness of this plugin, and can't help but think if the Neovim guys n gals don't want implement a feature to change the order of the buffers, then why not try and implement this feature as an opt-in feature for this plugin, ie. don't change the default behavior we have, but rather if one wants to change / rearrange the buffers on the tabline, then create a branch that has this experimental feature.

That said, I can't help but think this seems like setting for a virtual buffer list. And can't help but think that it would be similar to how aliases work on a *nix filesystem, ie. we don't modify the original buffer number but rather create a dictionary that updates a pointer to the actual buffer.

[PaulSt]

Hi,
I have a follow up question. I can totally see, that a move command will make this project bloated. However, would it be possible to sort the buffers in a predefined way, i.e. by file endings for example, or file names. I am asking, because when programming in c++, I would really enjoy it, if my cpp file and corresponding header file would stay right next to eachother.
Cheers!

[ap]

That does require less UI than manual moving of buffers. OTOH it requires more configurability… and I’m really unsure what level of flexibility would make this a broadly useful feature. In that regard it would be useful if you can cite any other existing Vim feature that does something related.

[kizza]

As an avid buftabline fan (and long-time user 🙏) I very much appreciate the prudency of this plugin (and it's author). I see there's a bit of conversation around sorting of buffers going on... however specifically for moving buffers, I thought I'd bundle and publish my own approach to reorder buffers (and thus, order buftabline "tabs"). Full disclosure - it achieves this by closing and reopening buffers (at the same selected line). It's imaginativly called vim-reorder-buffers, and if its own prudency and simplicity provides any wins for others - that's great.