build_grammars adapts the functionality that previously came from
helix-syntax to be used at runtime from the command line flags.
fetch_grammars wraps command-line git to perform the same actions
previously done in the scripts in #1560.
This is not strictly speaking necessary. tree_sitter_library was used by
just one grammar: llvm-mir-yaml, which uses the yaml grammar. This will
make the language more consistent, though. Each language can explicitly
say that they use Some(grammar), defaulting when None to the grammar that
has a grammar_id matching the language's language_id.
helix-syntax mostly existed for the sake of the build task which
checks and compiles the submodules. Since we won't be relying on
that process anymore, it doesn't end up making much sense to have
a very thin crate just for some functions that we could port to
helix-core.
The remaining build-related code is moved to helix-term which will
be able to provide grammar builds through the --build-grammars CLI
flag.
Here we add syntax to the languages.toml languge
[[grammar]]
name = "<name>"
source = { .. }
Which can be used to specify a tree-sitter grammar separately of
the language that defines it, and we make this distinction for
two reasons:
* In later commits, we will separate this code from helix-core
and bring it to a new helix-loader crate. Using separate schemas
for language and grammar configurations allows for a nice divide
between the types needed to be declared in helix-loader and in
helix-core/syntax
* Two different languages may use the same grammar. This is currently
the case with llvm-mir-yaml and yaml. We could accomplish a config
that works for this with just `[[languages]]`, but it gets a bit
dicey with languages depending on one another. If you enable
llvm-mir-yaml and disable yaml, does helix still need to fetch and
build tree-sitter-yaml? It could be a matter of interpretation.
The submodules system is being replaced with a command-line flag
hx --fetch-grammars
Which shallow-clones grammar repositories at the given revision and
hx --build-grammars
For building grammars separate of the initial compilation of helix.
Why remove submodules?
* Cloning helix in general takes a long time because of the submodules,
especially when the submodules are not fetched as shallow
* Packaging is consistently painful no matter the package-manager
* It is quite difficult to devise a scheme where users can declare
a desired set of grammars and implement it with submodules
This commit fully removes the existing tree-sitter submodules from
the tree (as well as the .gitmodules file which is no longer used).
* Move runtime file location definitions to core
* Add basic --health command
* Add language specific --health
* Show summary for all langs with bare --health
* Use TsFeature from xtask for --health
* cargo fmt
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
https://github.com/nix-community/dream2nix is a fairly new and
cool-looking project for adapting upstream package manager outputs
(lockfiles mostly it would seem) for nix.
This should improve the ability to cross-compile. As a more concrete
measure of improvement, `nix flake check' now succeeds 🎉
* Add arrow key mappings for tree-sitter parent/child/sibling nav
This helps my use case, where I use a non-qwerty layout with a
programmable mechanical keyboard, and use a layer switching key (think
fn) to send left down up right from the traditional hjkl positions.
* Add new bindings to docs
closes#1746
The queries for Go were updated in ddbf03613d.
The old ref was before this commit, so running helix from the flake
nix flake run github:helix-editor/helix/d62ad8b595a4f901b9c5dba1bb6e8f70ece395bf -- path/to/file.go
will crash because the old grammar's query analysis will fail (because `iota`
was not yet a named node).
This commit updates the version of the grammars that we pull down when building
the flake so that the queries match the grammars. We'll have to do an update like
this whenever a grammar is bumped in a breaking way (which happens fairly often
in tree-sitter) until #1659 comes along and the version of the grammar becomes
tied to the version declared in source.
* Fix bug with auto replacing components in compositor
This was last known to be working with 5995568c at the
time of commit, but now doesn't work with latest rust
stable.
The issue probably stems from using
std::any::type_name() for finding a component in the
compositor, for which the docs explicitly warn against
considering it as a unique identifier for types.
`replace_or_push()` takes a boxed `Component` and
passes it to `find_id()` which compares this with a
bare Component. `type_name()` returns `Box<T>` for
the former and `T` for latter and we have a false
negative. This has been solved by using a generics
instead of trait objects to pass in a `T: Component`
and then use it for comparison.
I'm not exactly sure how this worked fine at the
time of commit of 5995568c; maybe the internal
implementation of `type_name()` changed to properly
indicate indirection with Box.
* Do not compare by type name in compositor find_id
* add workflow for pushing nix flake artifacts to Cachix
* add docs on using the cachix cache from nix
* remove submodule clone from cachix workflow
* remove flake check
* add basic completion replay
* use transaction as the last completion
* completion replay only on trigger position
* cache changes in CompletionAction
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
Treesitter captures can contain multiple nodes like so:
```
(line_comment)+ @comment
```
This would match each line in a comment as a separate
`@comment` capture when what we actually want is the
whole set of contiguous `line_comment` nodes to be
captured under the `@comment` capture. This commit enables
this behaviour.
* Implement buffer-close-all
* Implement buffer-close-others
* Refactor all buffer close variants to use shared logic
* Fix clippy lint
* Docgen for new commands
* Shorten error message for attempting to close buffers that don't exist
* Refactor shared buffer methods to pass only editor, not whole compositor
* Switch signature of bulk buffer closing to use slice of DocumentIds
Addresses feedback that accepting an IntoIterator implementor is too
much for an internal. Also possibly saves some moving?