Tab completion on file names

I have been working on a project that has a LOT of files with the same prefix, lets say it is “dumbPrefix”.

  • dumbPrefix-additional-very-long-names-and-stuff
  • dumbPrefix-other-very-long-names-and-stuff
  • dumbPrefix-some-very-long-names-and-stuff
  • … 57 more files with the same prefix …

now, on my command prompt I type

  • dum<tab> it completes to the first common part, so I get dumbPrefix- and then I get a list of matching, this is great because I can often type one more char and then tab complete, so I might just type dum<tab>o<tab> to get dumbPrefix-other-very-long-names-and-stuff.

Kakoune on the other hand will turn dum<tab> into the FIRST FULL MATCH (in this case dumbPrefix-additional-very-long-names-and-stuff) , which means to fix it, I have to remove all the bad parts of the match or tab-cycle to it. Both are not ideal.

You can Shift + Tab to revert the expansion.

See also the proposal (#1818) for a select mode.

On the plus side, Kakoune will generally let you type dumo<tab>, or even o<tab> for the same effect.

It is annoying that it differs from the conventions of readline and other tools that follow its example. I wonder if there’s a config option to make readline more like Kakoune.

I decided some time ago to embrace fuzzy matching in Kakoune command line, which deviated quite a lot from readline usual behaviour. I think its still a pretty good tradeoff, however I think we lack a prompt binding that would complete common prefix, this way it would be possible to just map <tab> to it for user prefering that behaviour.

I am embarrassed to say that I wasn’t really using the full power of fuzzy matching! My habits got in the way, I was hitting tab too early. When you get over the hump, it is amazing. I need to write a little guide for others!

I want to chime in with other issue I have with file name completion. When one uses tab to select a directory candidate, there is no nice way to mark that entry as your choice and get further file completions for chosen directory.

Back when I used spacemacs, finding file was a fluid experience. It didn’t have this issue, because candidate navigation and selection bindings were separate. So once the desired candidate was selected, upon hitting the accept binding it either opened that file or continued completion for the chosen directory.

As of right now, it seems that hitting unused key binding continues the completion from selection, but you would still have to use different keys for opening a file and navigating directories, making it bit awkward to navigate file tree.

Another nice thing I miss about spacemacs file finding is going up one directory, effectively removing last directory from input bar. Best bet right now is to use delete word backward, but that might require deleting several times. I guess one can simulate this by creating hacky binding that escapes to draft buffer to edit the input line.

1 Like

I tend to just toss another / in … but yeah, it is out of like not knowing the right thing to do at that point.