wincent
Implement "Go to anything"
Snipping from an email that I received from @lencioni:
One of the things that I used constantly in Sublime was the jump-to-file with fuzzy finding command. Command-T does this. Sublime also had a jump-to-symbol-in-the-current-file command that worked with the same fuzzy finding and it was a great way to bounce around a piece of code. This was actually the primary way I navigated my code.
They happened to implement this as a "go to anything" feature where the
@denotes the beginning of a symbol.Here's a demo I found of it, probably fastest just to watch this: https://www.youtube.com/watch?v=Q0OtfjgnoLA
They also open the file and go to the symbol as you type or scroll around in the list of options, which is helpful for determining if it is actually the thing you want, but that is a separate feature.
Let me know what you think!
This is an interesting idea. I can see a few incremental ideas that would take us towards it.
First one is to implement a dumb find-in-file finder, that would match against all text (not just "symbols") in the current file. This would be relatively easy to implement, and once it existed we could test to see whether the current ordering mechanism (by match score) makes any sense, or the preserve-order-in-file ordering as seen in that video makes more sense.
Another step could be to perform some dumb tokenization for this finder instead of doing a raw text match; this could be done using some simple regexes, but obviously it wouldn't have any language-specific goodness in it. It would, nevertheless, find identifier-like things.
Subsequently, we could look at plugging in some other source that has actual symbol information. This could be Vim's tags, filtered to the current file, or it could be something else entirely like plugging into YouCompleteMe.
Obviously, the further we go, the harder these steps will be.
Finally there's the possibility of merging the symbol-nav with the existing file finding. I see two ways to do this. One is like in the video where "@" is used as an explicit indicator that the following text should match a symbol. The other is to simply allow mixed types in the search space: for example, typing "foo" would show me files, buffers, or identifiers matching the string. The more things we add to this "omni" finder, the harder it will be to make it performant of course (for example, the file finder performs well on enormous code bases, but the tag finder still struggles a lot with those; combining them would make performance tank in large repos).
Another dimension we can consider is the scope of the find-within feature; it could be scoped to current file, all currently open buffers, or files within a repo (could easily get very slow unless we rely on an external index like the tags file).
One thing that I see as likely to happen is the dynamic "reveal as you type" feature shown in the video (ie. where you type "foo@bar" and you see the contents of the file matching "foo" with the line containing the definition of "bar"). Getting this to happen in Vim is not impossible, but it would be quite a bit more work than just adding a new scanner/finder or two.
Thanks for the suggestion, @lencioni. Let me know if you have any thoughts on any of these options.
Thanks for the thoughtful response. I think what you outlined makes sense.
My first thought was that you could hook into tags. Although I haven't used it before, Tagbar might be worth checking out. I'm not sure how this would work on very large codebases, and tags aren't really perfect either.
I wonder if you could hook into Vim's syntax highlighting somehow? That might give you a good compromise between tags and regexes. But maybe it wouldn't work well enough across the board to make sense anyway.
Alternatively, since you only need this for the current file, would it make sense to run ctags on the current file on-the-fly? That would give you better tags. The bummer here is the added dependency and the lack of built-in support for newer languages in exuberant ctags (but that could be resolved by adding regex configuration at the point of execution).
As for merging the symbol-nav with the existing file finding, that would be nice but is definitely not as important to me as just having symbol-nav.
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.