wincent
Prioritize results with the same dirname/dirpath than the file on the current buffer
When I'm editing a/b/c/file.cc, it would be easier to type "file" and have a/b/c/file.hh show up in the top of the list, instead of copying the current path every time.
I can understand that the goal is to be "path-oriented", but I think something like this would be really convenient.
If all you really want is to edit a file in the same directory there are a couple of much more direct ways of achieving that; like :e %<tab> (which fills in the path of the currently-edited file, and you can backspace and edit it to taste, with tab completion), or a mapping like this one: https://github.com/wincent/wincent/blob/cb2007a4ab7286448e392cdb21066edb629cac60/.vim/plugin/mappings.vim#L16-L17 (which binds <leader>e to prepopulate the :e prompt with the current file's directory, from where you can tab complete).
I suggest this because the scoring algorithm is a fairly delicately tuned beast, and it's hard to boost for some local heuristic without making other use-cases suffer.
Yes, but that's not really what I meant. When working on huge codebases, you can have a lot of files named with things in common in their name and path. What I suggested was to prioritize the ones "near" the file you're editing, because that's something you do a lot. If it's too complicated to implement, that's not a big deal, but I think that it could be a huge improvement for most use cases. If it's relatively easy to tinker with, maybe playing a bit with the scoring would show if it's an improvement or not? Maybe I can try to see what can be done!
Yeah, that may make sense for some projects (although it sounds pretty context dependent; there might be contexts where this heuristic actually makes it harder to find things, as the things you're looking for may be in just the opposite place, far away from the current file). If you look at the code, you'll see it's not too complicated, but striking the right balance is probably going to be pretty tricky, and each piece of additional work you do will slow down the matching algorithm, so it needs to be weighed carefully against the degradation you'd see in very large projects.
I like how Command-T isn't context-dependent in this fashion. I want to be able to strike the same keyboard combination and always end up with the same file (given that no new files have been added in the meantime that would change that).
@seirl: In your case, I wonder if a.vim could help? http://www.vim.org/scripts/script.php?script_id=31
I'm new to Command-T (come from FuzzyFinder) and miss (or can't find) one function of FuzzyFinder that I liked very much and it works pretty much like what @seirl requests so I add my request here rather than opening a new issue. I think this would satisfy @seirl's needs as well: Add the option to show files in the same dir as the file that's in the currently visible buffer so only files in the same dir show up. It is written here.
I would have made a PR if I knew how to build this into Command-T but I've got no idea :)
Thanks for the beautiful (it is now already) plugin anyway!
Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on[^patches]. Feedback issue for 6.0.x is here:
- https://github.com/wincent/command-t/issues/393
[^patches]: Patches and PRs would be welcome, but my personal efforts are going to be directed towards main.