Add labelled buffer picker

[leath-dub]

This is akin to https://github.com/leath-dub/snipe.nvim. You essentially have a dictionary of characters which are used to generate tags for the currently open buffers. You can see attached the effect with many open buffers:

Looking at the screenshot example, if you press the key sequence sg, it will bring you to the buffer with helix-core/src/editor_config.rs open in it.

The changes extend the Picker struct to allow you to disable the prompt and have custom key event handling, while also adding a new command for the labelled buffer picker. Wasn't really sure how to handle extending the picker to not allow for a prompt.

This is draft, as I would love some feedback around the code, I am not a rust dev regularly and I am of course new to the helix codebase (so far well done btw ! - it is very nice to navigate).

I also understand this is more of a personal scratch to itch, but I thought I would share in case you want the changes also.

[nik-rev]

So this is like gw but for buffers? WOW, that's really cool!

[nik-rev]

this isn't really an "alphabet"

[leath-dub]

I was just using the same terminology that is already used for the gw feature. It is called jump_label_alphabet.

[leath-dub]

Just pushed some fixes there, not sure what the etiquette around resolving review comments (can the reviewee click the resolve button?).

Apart from fixes according to the comments by @nik-rev, I also realised I was using a string unecessarily and fixed that.

[nik-rev]

Just pushed some fixes there, not sure what the etiquette around resolving review comments (can the reviewee click the resolve button?).

Apart from fixes according to the comments by @nik-rev, I also realised I was using a string unecessarily and fixed that.

the comments are just some small things that popped into my mind, feel free to resolve any of them. Great work on this PR!!

[leath-dub]

One thing I wasn't sure about was what to do when the user types the wrong characters. Right now I just have the key recording reset.

[nik-rev]

I can't compile your PR

helix is on 1.76

[leath-dub]

I can't compile your PR

Ooh what version of rust does helix use? I think I am on nightly

[nik-rev]

1.76 as specified in rust-toolchain.toml

[leath-dub]

1.76 as specified in rust-toolchain.toml

cool, Ill fix that now.

[RoloEdits]

Helix tracks to firefox's MSRV. use was introduced in 1.82.0, which just so happens to be the next (estimated) MSRV, which is april first. Might be fine to leave this for now, as the MSRV for helix would support that in 8 days (as long as the capture rules still work).

[leath-dub]

Helix tracks to firefox's MSRV. use was introduced in 1.82.0, which just so happens to be the next (estimated) MSRV, which is april first. Might be fine to leave this for now, as the MSRV for helix would support that in 8 days (as long as the capture rules still work).

I will check if I fix the issue on the old version that it still compiles on latest, and if it does I think we should just target the older version.

[leath-dub]

OK so it works on helix's toolchain and 1.85.0 (latest) toolchain too.

[leath-dub]

I have been using this branch myself for the past few days and have not had any issues, so I changed it from draft just there - I am pretty happy that there are no glaring issues

[the-mikedavis]

IMO this fits better in the plugin space. I don't want competing workflows for basic stuff like switching buffers. (I also don't like the bufferline and the feature creep that has caused, for comparison.)

[leath-dub]

IMO this fits better in the plugin space. I don't want competing workflows for basic stuff like switching buffers. (I also don't like the bufferline and the feature creep that has caused, for comparison.)

I agree somewhat in that there are features already in helix that feel like they should be plugins. I guess the question is whether you want to only have some things in core until plugin support comes and you can test the breadth of API by moving these features into plugins. This is kinda what I assumed with some of the features like gw and bufferline

[leath-dub]

IMO this fits better in the plugin space. I don't want competing workflows for basic stuff like switching buffers. (I also don't like the bufferline and the feature creep that has caused, for comparison.)

I agree somewhat in that there are features already in helix that feel like they should be plugins. I guess the question is whether you want to only have some things in core until plugin support comes and you can test the breadth of API by moving these features into plugins. This is kinda what I assumed with some of the features like gw and bufferline

Edit: this is also a good candidate as it is built on top of the built-in selection menu.

[the-mikedavis]

There are things that could eventually be moved out into "tier 1" plugins (i.e. shipped with the editor, same as Kakoune's scripts like windowing) like the EditorConfig integration. I don't want to accept features that we would eventually remove entirely though and I don't see us maintaining this as a kind of "tier 1" plugin in the long run. Similar with bufferline and in retrospect I wish we hadn't merged it to begin with.

[leath-dub]

There are things that could eventually be moved out into "tier 1" plugins (i.e. shipped with the editor, same as Kakoune's scripts like windowing) like the EditorConfig integration. I don't want to accept features that we would eventually remove entirely though and I don't see us maintaining this as a kind of "tier 1" plugin in the long run. Similar with bufferline and in retrospect I wish we hadn't merged it to begin with.

I understand, I will maintain this as a fork anyway. It is a small feature overall, but I understand feature creep happens bit by bit - rarely big changes.