"wildmode" / bash-like completion behavior for path completion in commands

[zaquestion]

Hopefully this is not a dup issue or config option I missed, although I'd be happy if it was, I tried my best and searched for many term variations to see if this had already been raised as an issue or existing config option. please forgive if I overlooked something.

In vim you can configure something call "wildmode" to control how paths get completed during commands (and probably other contexts. By default the behavior is seemingly identical to helix, and what I might call "zsh-style" path completing as the default path completion behavior in zsh is similar. What I'm looking for is path completion behavior similar to bash's default or what the "wildmode" settings below provide. To be clear, I'm not looking for a general purpose configuration like vim's wildmode, I'd be entirely happy with a way to switch the mode without fine control.

set wildmode=longest,list

I'll refer to this as "bash-style" for simplicity

Say you have a directory structure like:

zaq:~/testdir
$ tree
.
├── a
├── b
└── c

With "bash style"

:o ~/t
<tab> expands to (assuming no ambiguity)
:o ~/testdir/
<tab> with ambiguity produces no completion and instead shows options back to the user
:o ~/testdir/
a/ b/ c/

With "zsh style" - or what hx does now

:o ~/t
<tab> expands to (assuming no ambiguity)
:o ~/testdir/
<tab> from this state will continue cycling to additional options within ~/

If you type something after  ~/testdir/ you can backspace or otherwise complete and cycle options within that dir
:e ~/testdir/a/
<tab>
:e ~/testdir/b/
...

Would we be open to supporting configuration of this behavior? I'm still fairly new to rust beyond AoC problems 😅 and unsure what the config option would even be call / part of. I think this would be somewhere in the filename_impl code-wise? That said, I know that function intersects with the file-picker stuff, and this feature should only really be related to path completion contexts where the user is building up a path (not fuzzy searching and selecting from a list like filepicker provides).

[pascalkuthe]

I don't think that really works with our completion system because our completions use a fuzzy matcher not a strict prefix match.

Wild match basically works as follows:

• If all files that start withthe current text share the same prefix that is longer than the existing prefix insert that prefix on tab
• if they don't then select the first option on tab (or show options first and select on next tab)

This works entirely different that our current completion infrastructure (which always shows completion options Sorten by fuzzy match score and then just cycles trough them).

I am not entirely set on which style of completions I prefer. Fuzzy matching catches typos/makes it easier to find things you don't know the exact name while wildmatch makes it faster to type if you do know the name.

The better discoverability of fuzzy matching does mean we want to keep it (for themes for example I don't think wildmatch makes much sense).

I am usually not a fan of adding more config options so I would lean towards not adding it. In practice the difference in speed is very small (and if you use fuzzy matcher right they can also be very fast it's juts a different way to type). Usually we just make one opiniated choice instead of just adding a bunch of options