This avoids costly conversions via byte_to_char (which are then
reversed back into bytes internally in Ropey).
Reduces time spent in slice/byte_to_char from ~24% to ~5%.
When the picker results output is empty, movement actions result in a panic:
```
thread 'main' panicked at 'attempt to calculate the remainder with a divisor of zero', helix-term/src/ui/picker.rs:420:31
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
This could be a no-op instead when the matches length is zero.
Currently match is finding the match based on the anchor rather than the
head (cursor) so this behavior is rather unexpected when user is doing
a match but a different item was matched instead when the selection is
more than one character.
`restore-keys` is a configuration option for the actions/cache action
which specifies fallback behavior. The [docs][docs] say it best:
> When a cache miss occurs, the action searches for alternate keys
> called `restore-keys`.
>
> If you provide `restore-keys`, the `cache` action sequentially
> searches for any caches that match the list of `restore-keys`.
> ... If there are no exact matches, the action searches for partial
> matches of the restore keys. When the action finds a partial match,
> the most recent cache is restored to the `path` directory.
So this improves caching when there's a miss. For example if I edit
`.github/workflows/languages.toml`, the current behavior is that the
cache for downloaded grammars will miss and all of them will need to
be fetched again. With `restore-keys`, we use the latest published
cache as 'good enough', we'll fetch whatever grammars changed, and
then at the end we publish a new cache under the new hash.
[docs]: https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#example-using-the-cache-action
* Add missing key bindings to keymap docs
* Add a note about readline bindings in insert mode
* Rewrite section on selection extend mode
We seem to have settled on this model, so no reason to say in the
docs that this is experimental. I also don't think we have any
movements that don't obey extend mode left.
* Fix table formatting
* Fix missing command for command palette binding
* Fix missed capitalization of descriptions in keymap docs
* Be consistent with multiple bindings in keymap docs
* Fix differently marked up commands in keymap docs
* Make special key capitalization consistent
Co-authored-by: Michael Davis <michael.davis@nfiindustries.com>
* Fix extra space in docs
Co-authored-by: Michael Davis <michael.davis@nfiindustries.com>
* A few more capitalizations of special keys in keymap docs
* Move a selection manipulation key map to the appropriate section in docs
* Move minor mode entry bindings to the minor modes section of keymap docs
* Add note about default register used in search commands in keymap docs
* Fix formatting of rebased addition
* Remove note about potential removal of select mode
It's been decided since to keep it
Co-authored-by: Michael Davis <michael.davis@nfiindustries.com>
79caa7b72b setup helix-term as the
default workspace member (which I believe is done to avoid building
xtask on every compile). This changes the behavior of 'cargo test'
though so that it only runs helix-term tests by default. To run all
tests, we switch to 'cargo test --workspace'.
Here we perform a shallow fetch using builtins.fetchTree. In order
to make this work, we need to specify the `ref' for any repository
that doesn't have `master' as its default branch (I'm not sure why
this limitation exists since we don't need this when performing
the shallow fetch in `--grammar build')
This `ref' field is ignored by helix, so I have left it undocumented
for now, but I could be open to documenting it.
This commit replaces the out-of-date builder in the flake which relied
on submodules for fetching and the compiler for building. Now we
disable fetching and building explicitly with the environment variable
and then use builtins.fetchGit and a derivation mostly derived from
upstream to compile the grammars.
Anecdotally, this is still quite slow as builtins.fetchGit does not
seem to do shallow clones. I'm not sure I see a way around it though
without recording sha256s, which seems cumbersome.
This restores much of the behavior that existed before this PR:
helix will build the grammars when compiling. The difference is that
now fetching is also done during the build phase and is done much
more quickly - both shallow and in parallel.
This is a bit of a micro-optimization: in the current setup we waste
a thread in the pool for a local grammar only to println! a message
saying we're skipping fetching because it's a local grammar.
This is a rather large refactor that moves most of the code for
loading, fetching, and building grammars into a new helix-loader
module. This works well with the [[grammars]] syntax for
languages.toml defined earlier: we only have to depend on the types
for GrammarConfiguration in helix-loader and can leave all the
[[language]] entries for helix-core.
The vision with 'use-grammars' is to allow the long-requested feature
of being able to declare your own set of grammars that you would like.
A simple schema with only/except grammar names controls the list
of grammars that is fetched and built. It does not (yet) control which
grammars may be loaded at runtime if they already exist.
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).
