search

zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
46.63k stars 2.65k forks source link

Improving project symbol search #13307

Open joeldrapper opened 2 months ago

joeldrapper commented 2 months ago

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

maxdeviant commented 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.

joeldrapper commented 2 months ago

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.

IkerAriz commented 3 weeks ago

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).

joeldrapper commented 1 week ago

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.