> Notice that both fzf and fzy ranked source/blender/makesdna/DNA_fileglobal_types.h higher than GNUMakefile. I believe this is because /make and _file in that

> Notice that both fzf and fzy ranked source/blender/makesdna/DNA_fileglobal_types.h higher than GNUMakefile. I believe this is because /make and _file in that path are on word boundaries and are ranked higher than UMakefile that is not on a word boundary. The reason for prioritizing word boundaries is so that you can type "sln" to match "SomeLongName". So while you are improving one use case you are probably breaking another one. I'm not sure how VSCode ranks GNUmakefile first, maybe they prioritize exact substring matches. It's still a heuristic that can fail. The ugly part is that it's not part of the "best match" algorithm that finds a global optimum. > It first attempts a match on the filename. If there is no match, it retries on the full candidate string Kakoune does the same, see https://github.com/mawww/kakoune/blob/019fbc5439ad884f172c324ebc928463eab9bc74/src/commands.cc#L167-L194 https://github.com/mawww/kakoune/blob/019fbc5439ad884f172c32... > Strict path matching means that the path segments of the query token cannot overlap between path segments in the candidate. nice