Annoying tab behavior when changing buffers.

[m-kru]

Here is the story. Lets assume we have more than 2 files opened and we want to change the buffer. After hitting :b we have following menu: If we want to open file name_2.py I just hit Enter and it is done. However, lets assume we want to open one of name_3.py, name_4.py or name_5.py files. After hitting Tab the first time we end up with: This is still name_2.py, the first hit of Tab is completely useless. You need one more Tab keystroke to go to the next position in the menu.

In my humble opinion this behavior could be improved. Instead of expanding the name of the first item, the first Tab keystroke should move focus to the next item and expand its name. This is what I would personally expect to happen after first Tab hit:

[alexherbo2]

With the new behavior, I would rather select name_3.py without expanding the candidates on Tab.

[m-kru]

Hmm, that would make more sense. The text after :b is just a filter. You can not open non-existing buffer. Anyway, I just wanted to point out that currently the first Tab keystroke is just useless action. To be honest, I do not understand your down vote. Have you down voted because you think everything is ok and there is no room to improve, or you just have not liked my proposal?

[EpocSquadron]

I actually think this is a valid concern. I work with designers and ui developers and this sort of thing is what we try to optimize away.

That said, I see what @alexherbo2 means. If the first tab does not expand the buffer name into the prompt, then why should the user expect the second tab to do so? In practice these seemingly simple solves lead to a host of edge cases that are far more difficult to work around than you would think.

However, in my personal usage I find using connect.kak to open the buffer list with fzf/skim to be far more intuitive a ui than pulling up the :b prompt autocomplete. I know a lot of people would rather use broot or fzf to open files as well. When everyone is working around it, it means the ux could use improvement. Pulling something that complicated in to the core editor is probably not something we want, for the same reason rust has a lean core lib. Someone will always make a better work around for their use case than you can build in. Said differently, we can't please everyone.

It's worth noting that in your example, you can type the unique part of a buffer name (say "4"), and then the first hit of tab completes "name_4.py". This is a sort of limited form of the fuzzy searching that fzf and others do, but somehow just doesn't feel as natural. I'd love to see more thinking around how to make autocomplete both more apparent and quicker to use in the prompt in general.

[alexherbo2]

@m-kru I downvoted because it is a surprising behavior.

[alexherbo2]

@EpocSquadron Maybe #1818?

[m-kru]

@EpocSquadron

However, in my personal usage I find using connect.kak to open the buffer list with fzf/skim to be far more intuitive a ui than pulling up the :b prompt autocomplete

Can you elaborate? Where can I find instructions so that I can try it.

[lenormf]

The current behaviour allows manually editing the first candidate. Jumping over to the second one would assume that users hit tab solely to select an entry no matter how long the list of candidates is.

[EpocSquadron]

@m-kru you can check out my dotfiles repo. Note that sk-in-files is a work in progress that doesn't function properly right now. The other two skim commands work fine though.

[alexherbo2]

@EpocSquadron In a recent version, you can remove the shell block and directly pipe to :edit and :buffer.

From:

:edit $(list-files | fuzzy-finder)

to:

list-files | fuzzy-finder | :edit

[EpocSquadron]

@m-kru just in case you were interested, I got that command to fuzzy search inside files with preview working.

[m-kru]

@EpocSquadron Thanks for letting me know. It is in your dotfiles, isn't it?

[EpocSquadron]

@m-kru yep. Right here for easy reference.