Consider allowing fuzzier matching tuned to file matching #1121

bitonic opened this Issue Jan 10, 2017 · 0 comments


None yet

1 participant

bitonic commented Jan 10, 2017

As far as I understand, right now we have one matcher for everything. This can be inconvenient for matching file paths, for example as described in .

However the matcher is (at least for me) less satisfactory than (say) what fzf uses for match files. One specific problem that bit me is that fzf helpfully favors matching file names rather than other parts of the path, so for example if you have

foo/bar/baz # this is the file I'm looking for
bar/<tons of files here> # this is an unrelated directory with `baz` in it

fzf fill have foo/bar/baz as the first hit, while currently kak shows all the files in bar/ first. I'm sure there are other tricks that we could copy from fzf, Sublime Text, etc.

There are two options:

  • Create a second matcher tuned for file paths
  • Special-case the normal matcher to have more sophisticated heuristics for things that look like file paths
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment