[Feature Request] Line numbers for selectable results

[fidgetingbits]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.52.1 (0.52.1)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

I use a voice coding system and where possible it is most convenient to select results from a cli tui by specifying a line number representing the distance from the current cursor. These line numbers aren't related to the content of what is being found, but rather only related to what can be selected from arbitrary results.

I've looked through the man page, issues, and other discussion and afaict this isn't currently possible (happy to be wrong though). What I'm describing is something like what atuin currently supports, which is shown in this gif.

To give a non-gif example, currently if I fuzzy find current folders I'd get something like this:

❯ fdd
>                                                                          ╭─────────────────────────────────────────────────────────────────────────╮
  598/598 ──────────────────────────────────────────────────────────────── │ total 884                                                          1/10││
> .                                                                       ││ drwxr-xr-x  2 aa users   4096  7月 22 09:43 changelog                  ││
  ./changelog                                                              │ -rw-r--r--  1 aa users  43498  6月 11 17:37 CHANGELOG.md               ││
  ./patches                                                                │ -rw-r--r--  1 aa users    126  6月 11 17:37 CONTRIBUTING.md            ││
  ./fonts                                                                  │ drwxr-xr-x  5 aa users   4096  7月 22 18:44 cursorless.nvim            ││

And what I'd like is something like this:

❯ fdd
>                                                                          ╭─────────────────────────────────────────────────────────────────────────╮
  598/598 ──────────────────────────────────────────────────────────────── │ total 884                                                          1/10││
0 > .                                                                       ││ drwxr-xr-x  2 aa users   4096  7月 22 09:43 changelog                  ││
1   ./changelog                                                              │ -rw-r--r--  1 aa users  43498  6月 11 17:37 CHANGELOG.md               ││
2   ./patches                                                                │ -rw-r--r--  1 aa users    126  6月 11 17:37 CONTRIBUTING.md            ││
3   ./fonts                                                                  │ drwxr-xr-x  5 aa users   4096  7月 22 18:44 cursorless.nvim            ││

This would allow me to issue a voice command like pick three and it would automatically be able to go to the ./fonts entry.

An important requirement is also that the line numbers could update as you scroll, so for example if I pressed down, note that the indexes would change to the following:

❯ fdd
>                                                                          ╭─────────────────────────────────────────────────────────────────────────╮
  598/598 ──────────────────────────────────────────────────────────────── │ total 884                                                          1/10││
    .                                                                       ││ drwxr-xr-x  2 aa users   4096  7月 22 09:43 changelog                  ││
0 > ./changelog                                                              │ -rw-r--r--  1 aa users  43498  6月 11 17:37 CHANGELOG.md               ││
1   ./patches                                                                │ -rw-r--r--  1 aa users    126  6月 11 17:37 CONTRIBUTING.md            ││
2   ./fonts                                                                  │ drwxr-xr-x  5 aa users   4096  7月 22 18:44 cursorless.nvim            ││

This allows me to always know the distance I need to say in order to select a specific entry.

Is this possible already or if not could it be considered as a new feature?

[junegunn]

So it's quite similar to relativenumber option of Vim.

The closest thing fzf can offer is the jump (or jump-accept) action you can bind to a key or event.

fzf --bind ctrl-j:jump

Hit CTRL-J to go into "jump" mode, and press a single-character index to go to a line.

Having said that, I don't use the feature as I find it more quicker to type in a few characters to the query to further narrow down the list and bring the most relevent item to the top position rather than moving my cursor upwards or downwards.

[fidgetingbits]

Thanks! That will be a good interim solution, although maybe a bit finicky still. I can automate it by having the voice command automatically enter jump mode after issuing the initial search. One quirk will be if the entry I want isn't already in the results, then I'd have to cancel out of jump mode to hone the results.

Having said that, I don't use the feature as I find it more quicker to type in a few characters to the query to further narrow down the list and bring the most relevant item to the top position rather than moving my cursor upwards or downwards.

Makes sense. When using voice for input it's often the opposite experience, it's often faster/easier to see the index you want to go in results and speak one command that automates pressing down N times and hitting enter, rather than dictate a couple different characters/words and then say enter, etc.

If I find time to take a stab at using jump mode as inspiration and adding something with line numbers (instead of characters) that can be displayed in the default result mode, would you consider accepting it?

[junegunn]

I can automate it by having the voice command automatically enter jump mode after issuing the initial search. One quirk will be if the entry I want isn't already in the results, then I'd have to cancel out of jump mode to hone the results.

I can imagine a workflow where 1. you confirm that the entry you want is in the result, 2. say "jump" to trigger jump mode, 3. then say the label to pick the item. This doesn't seem that different from your initial suggestion. pick three vs jump d.

would you consider accepting it?

I'm not sure, to be honest. The rendering code is already very complicated due to the large number of options fzf currently has, and I'd like to avoid adding more options that affect the rendering of the list unless it's necessary.

[fidgetingbits]

Appreciate you taking the time to respond.

I can automate it by having the voice command automatically enter jump mode after issuing the initial search. One quirk will be if the entry I want isn't already in the results, then I'd have to cancel out of jump mode to hone the results.

I can imagine a workflow where 1. you confirm that the entry you want is in the result, 2. say "jump" to trigger jump mode, 3. then say the label to pick the item. This doesn't seem that different from your initial suggestion. pick three vs jump d.

So I think the distinction here only really comes to light when you use voice to control computer/keyboard I think. The important point is that by having the labels assigned to lines in advance I can immediately see my target and thus speak a single command 'pick three' in one utterance. In the jump case I'd have to first speak 'jump' (or whatever) to toggle the labels. But here I then have to wait for the voice system to recognjze and issue the spoken command, and only then the labels come up. Then I have to speak the target label and wait again for it to register via voice. A single spoken command is much more ergonomic when using voice. This is an accessibility problem that most people won't run into.

If instead of relative line numbers the jump labels had an option to just always be shown and then one could issue a single spoken command 'jump d' to actually trigger the jump then that would be equally as gold I think. If that's what you were implying then that sounds good to me too :D

I entirely agree when using keyboard this request isn't very useful, as two keystrokes to quickly trigger labels, hit label key, involves no real waiting.