mirror of https://github.com/helix-editor/helix
parent
2f6a113fbe
commit
310bc04f23
@ -0,0 +1,24 @@
|
||||
Syntax symbol pickers
|
||||
==
|
||||
|
||||
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.
|
||||
|
||||
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 - 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 set up 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.
|
||||
|
||||
GitHub already uses tree-sitter like this to provide [imprecise code navigation](https://docs.github.com/en/repositories/working-with-files/using-files/navigating-code-on-github#about-navigating-code-on-github). It should be possible to find definitions and references as well like `gd` and `gr` - this is left as a follow-up.
|
||||
|
||||
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:
|
||||
|
||||
```toml
|
||||
[[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.
|
||||
|
||||
---
|
||||
|
||||
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`).
|
||||
|
||||
Also this PR needs docs on writing `symbols.scm` queries.
|
@ -0,0 +1,130 @@
|
||||
(self) @variable.builtin
|
||||
|
||||
(unit_definition (identifier) @function)
|
||||
|
||||
(parameter (identifier) @variable.parameter)
|
||||
|
||||
((pipeline_reg_marker) @keyword)
|
||||
|
||||
(scoped_identifier
|
||||
path: (identifier) @namespace)
|
||||
(scoped_identifier
|
||||
(scoped_identifier
|
||||
name: (identifier) @namespace))
|
||||
|
||||
((builtin_type) @type.builtin)
|
||||
|
||||
((identifier) @type.builtin
|
||||
(#any-of?
|
||||
@type.builtin
|
||||
"uint"
|
||||
"Option"
|
||||
"Memory"))
|
||||
|
||||
((identifier) @type.enum.variant.builtin
|
||||
(#any-of? @type.enum.variant.builtin "Some" "None"))
|
||||
|
||||
((pipeline_stage_name) @label)
|
||||
|
||||
((stage_reference
|
||||
stage: (identifier) @label))
|
||||
|
||||
[
|
||||
"pipeline"
|
||||
"let"
|
||||
"set"
|
||||
"entity"
|
||||
"fn"
|
||||
"reg"
|
||||
"reset"
|
||||
"initial"
|
||||
"inst"
|
||||
"assert"
|
||||
"struct"
|
||||
"enum"
|
||||
"stage"
|
||||
"impl"
|
||||
"port"
|
||||
"decl"
|
||||
"mod"
|
||||
"where"
|
||||
"trait"
|
||||
] @keyword
|
||||
|
||||
[
|
||||
"use"
|
||||
] @keyword.import
|
||||
|
||||
[
|
||||
"$if"
|
||||
"$else"
|
||||
"$config"
|
||||
] @keyword.directive
|
||||
|
||||
((comptime_if ["{" "}"] @keyword.directive))
|
||||
((comptime_else ["{" "}"] @keyword.directive))
|
||||
|
||||
((attribute) ["#" "[" "]"] @punctuation.delimiter)
|
||||
|
||||
[
|
||||
"else"
|
||||
"if"
|
||||
"match"
|
||||
] @keyword.control.conditional
|
||||
|
||||
(bool_literal) @constant.builtin.boolean
|
||||
(int_literal) @constant.numeric.integer
|
||||
|
||||
[
|
||||
"&"
|
||||
"inv"
|
||||
"-"
|
||||
"=>"
|
||||
">"
|
||||
"<"
|
||||
"::<"
|
||||
"::$<"
|
||||
"="
|
||||
"->"
|
||||
"~"
|
||||
"!"
|
||||
] @operator
|
||||
|
||||
|
||||
((op_add) @operator)
|
||||
((op_sub) @operator)
|
||||
((op_mul) @operator)
|
||||
((op_equals) @operator)
|
||||
((op_lt) @operator)
|
||||
((op_gt) @operator)
|
||||
((op_le) @operator)
|
||||
((op_ge) @operator)
|
||||
((op_lshift) @operator)
|
||||
((op_rshift) @operator)
|
||||
((op_bitwise_and) @operator)
|
||||
((op_bitwise_xor) @operator)
|
||||
((op_bitwise_or) @operator)
|
||||
((op_logical_and) @operator)
|
||||
((op_logical_or) @operator)
|
||||
|
||||
|
||||
[
|
||||
(line_comment)
|
||||
(block_comment)
|
||||
] @comment
|
||||
|
||||
[
|
||||
(doc_comment)
|
||||
] @comment.block.documentation
|
||||
|
||||
|
||||
((identifier) @type
|
||||
(#match? @type "[A-Z]"))
|
||||
|
||||
((scoped_identifier
|
||||
name: (identifier) @type)
|
||||
(#match? @type "^[A-Z]"))
|
||||
|
||||
((identifier) @constant
|
||||
(#match? @constant "^[A-Z][A-Z\\d_]*$"))
|
||||
|
@ -0,0 +1,27 @@
|
||||
|
||||
[
|
||||
(unit_definition)
|
||||
(struct_definition)
|
||||
(enum_definition)
|
||||
(enum_member)
|
||||
(impl)
|
||||
(mod)
|
||||
(argument_list)
|
||||
(let_binding)
|
||||
(block)
|
||||
(tuple_literal)
|
||||
(array_literal)
|
||||
(paren_expression)
|
||||
(turbofish)
|
||||
(generic_parameters)
|
||||
(named_unpack)
|
||||
(positional_unpack)
|
||||
(tuple_pattern)
|
||||
] @indent
|
||||
|
||||
[
|
||||
"}"
|
||||
"]"
|
||||
")"
|
||||
] @outdent
|
||||
|
Loading…
Reference in New Issue