zed
zed copied to clipboard
zed-industries
Improving project symbol search
Check for existing issues
- [X] Completed
Describe the feature
There seems to be a difference between the way buffer symbols and project symbols are generated. I think buffer symbols use Tree-sitter while project symbols use the language server? Buffer symbols seem to be much faster and more accurate and reliable.
Would it makes sense to unify these and have Tree-sitter generate project symbols too? Additionally, project symbols seem to be generated lazily. Sometimes you need to open the relevant file before the symbols become available.
Would it be possible to configure Zed to build and maintain an index of project symbols up-front? I appreciate the performance and memory usage considerations, but I have 128GB of memory and would love to be able to search my whole project and jump straight to the relevant symbol.
If applicable, add mockups / screenshots to help present your vision of the feature
No response
I don’t think using Tree-sitter for project symbol search makes sense, as it means we’d have to open each file in the project, parse it with Tree-sitter, and then collect up the results.
While we could use an index to speed this up, it does seem like we’re replicating language server features at that point.
Whereas the language server already has a way of introspecting the project for searchable symbols.
I guess it depends on the language server, but if we take RubyLSP / Solargraph as an example, they are pretty slow to start and they index lazily. The project symbol search often displays incorrect symbols from old caches that haven’t been updated or nothing at all because it hasn’t indexed the project properly.
I don’t know how much memory we’re talking about but I would imagine a Tree-sitter index of each file could be utilised for other things like highlighting when jumping to that file. I would happily dedicate like 40GBs of memory to this if that’s what it took. For now, I use the file search first and then use the buffer symbols after opening the file.
Perhaps this should be solved in the language servers. I had just noticed that buffer symbols weren’t impacted by this and always seem to be perfect and fast.
I'd find a treesitter-based global search very useful, especially in mixed-language setups. For instance, a project that includes a C++ library with a function X, a corresponding python binding module for that C++ library, and a mix of C++ and Python code that calls X. A more specific search for any X call sites, regardless of language, could offer a nice improvement over grep-based search. I imagine this could be accomplished with sufficiently configured language servers, but a useful symbol search that works out of the box would be a pretty good option (especially when warming up to a new project).
I would imagine a project-wide tree-sitter symbol index would be very useful for AI too. AI tools could use multi-step prompts where the AI can drive, searching for symbols and pulling in context.
The lack of this feature is a deal-breaker for me. LSPs don't exist for many languages (which I use). Currently I use Sublime Text, which does support global indexing, and it's indispensable.
It’s not a deal breaker for me but it would be incredibly useful. The tree-sitter outlines are so much more reliable than a lot of language servers.
Worth noting that not only many languages lack a language server, but also that LS-based references don't work across languages. Which is a shame, because in multi-language projects, you often end up with many cross-language references embedded in comments. Like in JS client code, you'd refer to a server Go type, where you'd refer to an SQL table, where you'd refer to a server API function, and so on. These kinds of references are very useful, and work seamlessly in editors with universal indexing (such as Sublime Text's "goto definition").
I second this request, it's definitely a dealbreaker. I work on a big multi-language project. Sublime Text just works. VS Code kinda works (slow, but possible to configure it to be acceptable).
I think there should be an option to use this for "Go to Definition" and "Find all references" as well. It wouldn't be as precise as LSP, but as long as you get a list of matches to choose from for the definition it should be more robust than LSP for some use-cases.
Yes! And we know it works because the outline view when you’re looking at a specific file is absolutely brilliant. We just need the ability to search all the outlines for all files.
Another improvement to the symbols search would be to allow filtering on filepath.
^^ imaging the result being filtered down to the object.rs match ^^
Perhaps using some special marker would be best SYMBOL NAME QUERY / FILE PATH QUERY. The reverse order could be done by / FILE PATH QUERY @ SYMBOL NAME QUERY
