* Generalised to multiple runtime directories with priorities
This is an implementation for #3346.
Previously, one of the following runtime directories were used:
1. `$HELIX_RUNTIME`
2. sibling directory to `$CARGO_MANIFEST_DIR`
3. subdirectory of user config directory
4. subdirectory of path to helix executable
The first directory provided / found to exist in this order was used as a
root for all runtime file searches (grammars, themes, queries).
This change lowers the priority of `$HELIX_RUNTIME` so that the user
config runtime has higher priority. More significantly, all of these
directories are now searched for runtime files, enabling a user to override
default or system-level runtime files. If the same file name appears
in multiple runtime directories, the following priority is now used:
1. sibling directory to `$CARGO_MANIFEST_DIR`
2. subdirectory of user config directory
3. `$HELIX_RUNTIME`
4. subdirectory of path to helix executable
One exception to this rule is that a user can have a `themes`
directory directly in the user config directory that has higher piority
to `themes` directories in runtime directories. That behaviour has been
preserved.
As part of implementing this feature `theme::Loader` was simplified
and the cycle detection logic of the theme inheritance was improved to
cover more cases and to be more explicit.
* Removed AsRef usage to avoid binary growth
* Health displaying ;-separated runtime dirs
* Changed HELIX_RUNTIME build from src instructions
* Updated doc for more detail on runtime directories
* Improved health symlink printing and theme cycle errors
The health display of runtime symlinks now prints both ends of the
link.
Separate errors are given when theme file is not found and when the
only theme file found would form an inheritence cycle.
* Satisfied clippy on passing Path
* Clarified highest priority runtime directory purpose
* Further clarified multiple runtime details in book
Also gave markdown headings to subsections.
Fixed a error with table indentation not building
table that also appears present on master.
---------
Co-authored-by: Paul Scott <paul.scott@anu.edu.au>
Co-authored-by: Blaž Hrastnik <blaz@mxxn.io>
Currently we always lower-case the grammar name when loading it. While it
is somewhat of an convention to name tree-sitter grammars in lowercase
there is no rule to enforce it.
This patch removes the lower-casing to allow all possible grammar names.
Signed-off-by: Christian Speich <cspeich@emlix.com>
New look:
```
Fetching 102 grammars
98 up to date git grammars
4 updated grammars
bash now on 275effdfc0edce774acf7d481f9ea195c6c403cd
beancount now on 4cbd1f09cd07c1f1fabf867c2cf354f9da53cc4c
c now on f05e279aedde06a25801c3f2b2cc8ac17fac52ae
c-sharp now on 53a65a908167d6556e1fcdb67f1ee62aac101dda
```
```
Building 102 grammars
100 grammars already built
2 grammars built now
["bash", "rust"]
```
When handling grammars, fetching and building is done in a thread
pool. Results are communicated over channels and the receiving
channel is closed on first error. This causes subsequent sends to
fail causing a mess in stderr. This ignores all SendErrors causing
only the first error to be printed.
Earlier in the builder we enable C++ (`.cpp(true)`) but only mention
the C compiler in the build failure message. Some grammars that have
C++ external scanners can provoke build failures in this step if a
C++ compiler isn't installed, so mentioning it in the error message
should help out debugging.
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.