Open joeldrapper opened 2 months ago
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.
Check for existing issues
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