Add `move_buffer_{left,right,start,end}` commands

[emilyyyylime]

Closes #10278. Default mapping: (let me know if you have better ideas)

• move_buffer_left: [[
• move_buffer_right: ]]
• move_buffer_start: [{
• move_buffer_end: ]}

#10077 was already closed as "encourag[ing] a more gui/mouse driven tab like workflow" but this is an even smaller and very straight-forward implementation. If the Helix team truly wants to discourage this type of workflow this badly, why leave the gn/gp commands in? #10278 shows there are a lot of users that would like this in Helix and personally at least I feel like I can get around faster by ordering my buffers spatially than by searching for them in a normally hidden menu every time I want to get to a different one. With the ordered approach I just always know where my file is, it doesn't keep changing, so I know exactly which commands I need to use to get to it, without opening the buffer picker and scanning through it.

Implementation

I added indexmap as a dependency for a simple drop-in-place implementation. I believe that a Vec should really be enough instead of any HashMap-like container, but after no responses from the team to my question on this matter, and a lot of friction in my attempts to switch a HashMap with a Vec due to how many places it was used in, I decided it's better to add a dependency than give up on this feature. goto_buffer (used by goto_buffer_prev, goto_buffer_next) is also now noticeably faster with very high counts (which was never a real use case but)

[rahil627]

encourag[ing] a more gui/mouse driven tab like workflow"

hmmmmm... no wonder why tab is unmapped! or, well, maybe people map it to escape.. or maybe some keyboards don't have caps lock..!

just a thought: if this feature isn't possible, what if tabs were automatically re-ordered to most-recently-used/accessed too, to match the buffer picker? in it's current state, i see no point in accessing buffers whose tabs are wayy off-screen.. (though, this would destroy this feature ☹️..)

[thomasschafer]

Would love to see this merged, but I'm skeptical it will be given previous discussions about not wanting to encourage a tab-like workflow. I find it much faster to work with tabs than using the recent buffer picker, though, and I don't find any link between tabs and a mouse workflow. (I ended up adding something like this to my own fork because I find it so useful.)

[wassson]

Sad to see no movement on this! I personally find a tab workflow much faster than using the buffer picker. Why even offer tabs in the first place if this is considered antithetical to the Helix philosophy?

[WizardUli]

I don't care about tabs. I just want always opened buffer picker somewhere on side with manual ordering.

[coolGi69]

Thx a lot for this patch!
For others looking here is a patch for v25.7.1 as this PR hasn't gotten updated to the latest version yet: 11790.v25.7.1.patch

And just for my 2 cents, I use tab positioning on Qutebrowser and like to have similar bindings between my programs. Tabs are essential to web browsing, and my workflow there is based around being able to switch between tabs and being able to move them.
I understand a text editor's role is different and they shouldn't act the same, but for me it's quite jarring when both have some sort of tab system but one doesn't allow me to move it.

Helix is great in its own regards, and tysm for the editor! But it'd be nice for this to be implemented for people like me.

[WizardUli]

We've got goto_buffer_next and goto_buffer_prev but they are almost worthless without an ability to give those next and prev parts some meaning. It would be very nice for maintainers to take an official stance on this as not to give people false hopes or waste their efforts.

[thomasschafer]

Given that the plugin system seems close to being merged, I imagine that the official stance will be to re-implement tabs via a plugin, which I think should be feasible

[WizardUli]

Given that the plugin system seems close to being merged, I imagine that the official stance will be to re-implement tabs via a plugin, which I think should be feasible

Perhaps goto_buffer_next and goto_buffer_prev should be removed from the core then. Does not make sense to have a feature there which is incomplete (to a point of being unusable) and never planned of being finished.