Syntax symbol pickers

[the-mikedavis]

This adds two new symbol picker commands that use tree-sitter rather than LSP. We run a new symbols.scm query across the file and extract tagged things like function definitions, types, classes, etc. For languages with unambiguous syntax this behaves roughly the same as the LSP symbol picker (<space>s). It's less precise though since we don't have semantic info about the language. For example it can easily produce false positives for C/C++ because of preprocessor magic. Prior art for this feature is GitHub's imprecise code navigation which I believe works the same way and leverages tags.scm queries. (I have no internal GitHub knowledge so this is an educated guess.) It should be possible to find definitions and references as well like gd and gr - this is left as a follow-up.

The hope is to start introducing LSP-like features for navigation that can work without installing or running a language server. I made these two pickers in particular because I don't like LSP equivalents in ErlangLS or ELP - the document symbol picker can take a long time to show up during boot and the workspace symbol picker only searches for module names. The other motivation is to have some navigation features in cases when running a language server is too cumbersome - either to install or because of resource constraints. For example clangd needs a fair amount of setup (compile_commands.json) that you might not want to do when quickly reading through a codebase.

This PR also adds commands that either open the LSP symbol picker or the syntax one if a language server is not available. This way you can customize a language to not use the LSP symbol pickers, for example:

[[language]]
name = "erlang"
language-servers = [{ name = "erlang-ls", except-features = ["document-symbols", "workspace-symbols"] }]

and <space>s will use the syntax symbol picker, while <space>s on a Rust file will still prefer the language server.

Some prior discussion of a feature like this is in #3518 talking about Ctags support. The idea here is similar but extracts tags/symbols with tree-sitter instead.

Outstanding question: how closely should we try to match LSP symbol kind? Not at all? Should we have markup specific symbol kinds? (For example see markdown's symbols.scm).

[EricHenry]

I'm having trouble getting this to work. I pulled down the branch, but when I try to load the symbol picker, without having lsp enabled, I get an error that No language server supporting document symbols or syntax info available. I am testing this on a rust project.

Any ideas?

[the-mikedavis]

There are only a few languages with symbols.scm queries so far: C, C++, Erlang, Elixir, Markdown and Python. Rust queries would need to be added. (Feel free to send a PR to this branch if you'd like. I always have rust-analyzer going so I haven't felt the need to add Rust yet.)

[cgahr]

I added symbols for typst: #12793

[poliorcetics]

Suggested change

	[example-queries]: https://github.com/search?q=repo%3Ahelix-editor%2Fhelix+path%3A%2A%2A/symbols.scm&type=Code&ref=advsearch&l=&l=
	[example-queries]: https://github.com/search?q=repo%3Ahelix-editor%2Fhelix+path%3A%2A%2A/symbols.scm&type=Code

Should lead to the same result without cruft in the URL

[poliorcetics]

is this still valid or is it used now ?

[poliorcetics]

Ordering them alphabetically here, in the docs and in matches will make it easier to avoid conflicts if more variants are added in the future, the current order encourages adding at the end

[poliorcetics]

dashmap can be very slow to free memory (though it's fast on all other operations).

In my personal experience, scc is better at memory reclamation, which is probably good for a picker (avoid lingering effects from mapping the whole workspace for example).

Of course, we probably want benchmarking results, it may not be an issue at all in practice