Generalised to multiple runtime directories with priorities

[paul-scott]

This is an implementation for #3346 See commit message for an overview.

Here are some thing to consider when reviewing.

Depending on how helix is packaged, it still might not be possible for some users to conveniently override runtime files. E.g. on AUR helix-git, /usr/bin/hx is a shell script that sets HELIX_RUNTIME to /usr/lib/helix/runtime before calling /usr/lib/helix/hx. Setting this env var is not necessary because helix already automatically checks for a runtime directory in the same directory as the executable. Setting it prevents ~/.config/helix/runtime from getting priority from the default runtime installation.

The docs suggest that the HELIX_RUNTIME is intended as an option to override a ~/.config/helix/runtime, which I agree could be useful and why I've initially kept this behaviour. However, if it looks like packager's and build-from-source installers want to use this env var for their default runtime install, then we might want to rethink the priority order as outlined in the commit message.

For consistencies sake you might want to consider if ~/.config/helix/themes should be deprecated since this commit makes it so that ~/.config/helix/runtime/themes can be used to the same effect. Before and after this commit the former always has the higher priority.

It just remembered that I haven't touched the user doc / book. I'll have to have a look and see where the new behaviour can be easily explained.

[archseer]

Priority should be (highest to lowest):

1. ~/.config/helix/runtime (user's configuration)
2. HELIX_RUNTIME (indicates the system's runtime, will be usually be under /usr/ for package installs, not writable)
3. current executable's directory (if all else fails, it might just be someone running it from a tarball)

The docs recommend setting HELIX_RUNTIME just because I felt it's simpler to use an env var than to copy files over and then forget to update them in the future.

This means that for grammar fetch & build we probably want to write into the first dir? Except on CI \cc @the-mikedavis

[paul-scott]

Priority should be (highest to lowest):

1. `~/.config/helix/runtime` (user's configuration)

2. `HELIX_RUNTIME` (indicates the system's runtime, will be usually be under `/usr/` for package installs, not writable)

3. current executable's directory (if all else fails, it might just be someone running it from a tarball)

The docs recommend setting HELIX_RUNTIME just because I felt it's simpler to use an env var than to copy files over and then forget to update them in the future.

This means that for grammar fetch & build we probably want to write into the first dir? Except on CI \cc @the-mikedavis

In that case how about:

1. sibling runtime directory to $CARGO_MANIFEST_DIR
2. subdirectory of user config directory (~/.config/helix/runtime)
3. $HELIX_RUNTIME
4. subdirectory of path to helix executable

Compared to the original behaviour this is just swapping 2 and 3.

I assume my 1 here is what the CI uses. In addition it seems like helix-git on AUR fetches and builds the grammars under 1, and then packages them up from there so they get installed under /usr/lib/helix/runtime.

I think it is best if this kind of packaging behaviour remains. It would be a pain if on updating a packager started putting (and overriding) the grammars under ~/.config/helix/runtime. A user might intentionally be trying to keep grammars in there to override the defaults.

[archseer]

Oh I agree, I forgot to list it above :) Just wanted to clarify the intended use of HELIX_RUNTIME

[gibbz00]

Should we also make use of XDG_RUNTIME_DIR? I'm personally not of fan of placing runtime files the .config folder.

[archseer]

It's orthogonal to this PR. https://github.com/helix-editor/helix/pull/2135 implements that but it should be rebased after this is merged

[paul-scott]

Oh I agree, I forgot to list it above :) Just wanted to clarify the intended use of HELIX_RUNTIME

I've now moved HELIX_RUNTIME down in priority below the user config runtime.

In terms of fetch and build, the behaviour is now that a cargo build will always put grammars in the runtime directory within the helix repo being built. HELIX_RUNTIME can no longer be used to change where they will automatically be fetched / built.

When a user calls hx -g fetch / build this is now always put in ~/.config/helix/runtime/grammars/.

None of this is hard-coded, it is just the way it works with the new priority ordering and how the implementation of fetch and build always grab the highest priority runtime directory.

I've modified the build from source instructions in the book to reflect some of this but not in that much detail.

Let me know if you would like to further tweak this.

[archseer]

Thanks! This was a much needed improvement 🎉