runtime Data Location

[theduke]

Currently the runtime data is supposed to live in ~/.config/helix/runtime, which is somewhat against the XDG spec.

Files like this should normally be placed in ~/.local/share/helix/.

~/.config should only hold user provided configuration.

[archseer]

So in a packaged installation the runtime folder would be installed into a system folder (for example /usr/lib/helix/runtime on Arch) then the binary is wrapped in a script that points HELIX_RUNTIME to the location.

I consider ~/.config/helix/runtime the place where users will be able to provide their own queries and grammars specific to their config.

For builds from source we currently recommend symlinking to that directory more for convenience: it's a frequent source of friction because users forgot to specify a HELIX_RUNTIME pointing to their runtime dir. In the future I definitely think that's the wrong thing to do. I guess we could recommend that users use a symlink in ~/.local/share/helix/runtime if building from source?

[pickfire]

~/.config should only hold user provided configuration.

I think it's a gray area here. Helix runtime contains some user configuration as well and users are welcome to edit it although being less used compared to config.toml.

[mmatous]

I'm in favor of changing current behavior.
Current fallback is executable's directory. I just had Helix scream at me because it wanted to put stuff in /usr/local/bin while running as a user.
Proposed improvements:

• disregard XDG_DATA_DIRS (/usr/local/share:/usr/share) for now
• look for config.toml in HELIX_CONFIG directory, default to XDG_CONFIG_HOME/helix, create if necessary
• same dir is default location of languages.toml
• config.toml may contain additional paths (languages.toml, data_dir, runtime_dir, log_dir), I disagree with todo notes in sources wanting envvar per dir, one is enough
• grammars should be separate from config, default to XDG_DATA_HOME/helix, create if necessary
• helix.log belongs to newest XDG addition, XDG_STATE_HOME/helix, create if necessary
• if XDG_ vars are empty, dump it all into HOME/.helix (or fallback to paths XDG usually uses? does anyone still put things in HOME? i know XDG isn't used by every *nix, but I don't know how crossplatform Helix is)

Even better solution would include Helix merging config and grammars from system dirs and user dirs and having fallbacks configurable at buildtime but meh. This should be enough for most usecases.

I'll make the PR, if you want.

[the-mikedavis]

Those sound good to me. We could fall back to XDG_CONFIG_HOME if we need to since that's what we currently use (although it doesn't make much sense xdg spec wise).

Having the grammars in the xdg data dir would also be an improvement for the failure mode described in #2023 (and IMO makes sense generally 👍 )

[flokli]

What's the status of these two PRs linked from here? Just ran into this again at #5411 (comment).

[go2null]

* if XDG_ vars are empty, dump it all into `HOME/.helix` (or fallback to paths XDG usually uses? does anyone still put things in HOME? i know XDG isn't used by every *nix, but I don't know how crossplatform Helix is)

@mmatous, would suggest to use the XDG defaults, that way, the implementation is fully XDG compliant and so no surprises.

[kirawi]

Neovim had a long discussion about this, and settled on using the OS-specific fallback: neovim/neovim#78
You can also see their response to a request similar to what you want: neovim/neovim#9352

As mentioned in #6747, most XDG-compliant programs interpret the spec as such. glib is an excellent example, so this is de facto standard behavior.