We use `which::which` in many crates, so `which` was a separate
dependency across all of them. We can centralize `which` into the
stdx crate so it's easy for all crates to depend on it.
I also moved the rest of `helix-view/src/env.rs` into helix-stdx's
`env` module since it only contained a thin wrapper around `which`
and `std::env`.
Previously this wasn't possible since helix-core depends on helix-loader,
so helix-loader couldn't use helix-core's path extensions.
We use the path normalization/canonicalization for the runtime directory
provided by the HELIX_RUNTIME environment variable. This improves a
scenario where you set a path containing a tilde. Now that path will be
expanded and normalized.
helix-stdx is meant to carry extensions to the stdlib or low-level
dependencies that are useful in all other crates. This commit starts
with all of the path functions from helix-core and the CWD tracking that
lived in helix-loader.
The CWD tracking in helix-loader was previously unable to call the
canonicalization functions in helix-core. Switching to our custom
canonicalization code should make no noticeable difference though
since `std::env::current_dir` returns a canonicalized path with
symlinks resolved (at least on unix).
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.
* 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>
* Split helix_core::find_root and helix_loader::find_local_config_dirs
The documentation of find_root described the following priority for
detecting a project root:
- Top-most folder containing a root marker in current git repository
- Git repository root if no marker detected
- Top-most folder containing a root marker if not git repository detected
- Current working directory as fallback
The commit contained in https://github.com/helix-editor/helix/pull/1249
extracted and changed the implementation of find_root in find_root_impl,
actually reversing its result order (since that is the order that made
sense for the local configuration merge, from innermost to outermost
ancestors).
Since the two uses of find_root_impl have different requirements (and
it's not a matter of reversing the order of results since, e.g., the top
repository dir should be used by find_root only if there's not marker in
other dirs), this PR splits the two implementations in two different
specialized functions.
In doing so, find_root_impl is removed and the implementation is moved
back in find_root, moving it closer to the documented behaviour thus
making it easier to verify it's actually correct
* helix-core: remove Option from find_root return type
It always returns some result, so Option is not needed
When looking up the runtime/ directory relative to the executable path,
canonicalize the path first in case the executable is a symbolic link.
Fixes#3768
