* Fix next/prev tree-sitter inconsistency
Before there where different results going to next or previous due to
sorting not dealing with multiple captures that start/end at the same
pos. I chose to prefer longer matches.
* Revert unnecessary change
* runtime config made clearer
* following Unix FHS
* we probably want to install Helix as a regular user without sudo access
* suggestions adopted from @the-mikedavis
* attempted to synthesise comments given
* capitalisation of second header
* required changes hopefully made
* we should have a match now
* Linux windows dir match
Previously the error message for this potential failure-case was
confusing: "no such file or directory". `hx -g fetch`, `hx -g build` and
the helix-term builder should bail early if the git binary is not
available.
Previously a count or register selection would be lost while opening
the command palette. This change allows using a register selection or
count in any command chosen from the command palette.
Previously the register selection (via `"`) would be lost in the middle
of any key sequence longer than one key. For example, `<space>f` would
clear the register selection after the `<space>` making it inaccessible
for the `file_picker` command.
This behavior does not currently have any effect in the default keymap
but might affect custom keymaps. This change aligns the behavior of the
register with count. Making this change allows propagating the register
to the `command_palette` (see the child commit) or other pickers should
we decide to use registers in those in the future. (Interactive global
search for example.)
Does not change any behavior other than making the tuple slightly
more idiomatic. Keymap infobox shows key events, then the respective
description. This commit makes sure that order is used from the get go,
rather than flipping it midway.