Override location of languages.toml

[crabdancing]

Helix has a --config path that lets you override the location of config.toml, but it doesn't seem to offer this ability for languages.toml. Being able to override this would be quite useful for rapid testing of configurations, declarative multi-versioned deployments, and systems with unusual directory structures, among other use cases.

Adding a --language-config flag would keep good symmetry with --config and make it easy to vary the file it's loading independently, in a similar fashion to Nushell's --config and --env-config.

[crabdancing]

I'm confused why this was converted to a discussion, seeing as how this is a feature that doesn't exist based on my reading of the docs & source code. Can you explain, @the-mikedavis?

[the-mikedavis]

We're trying to keep the issues cleaner than they have been by converting anything non-actionable to a discussion. For example bug reports that need more investigation or enhancements that need additional design or discussion about how or whether they should be implemented.

[kirawi]

See #7102

[the-mikedavis]

Eventually we want to consolidate language config into regular config, #10389. Then the -c/--config flag is all that will be necessary to override the location.

[crabdancing]

@kirawi Yes, I'm aware of this feature. It doesn't address my use case, though. .helix is another hardcoded dynamic directory path, rather than a declaratively-controllable directory path. In fact, in the future I'm planning to disable it entirely because I want to use Helix on very high security systems, and I consider the .helix system something of a (relatively) minor vulnerability that I don't want to build infrastructure on top of.

As I said before, I'm interested in declarative multi-versioned deployments. So, for example, Nix deployments that 'bake-in' their configuration files using arguments or environment variables, such that the application ignores the conventional paths entirely.

In addition, .helix is something that isn't compatible with having two different versions of Helix on the same system running without stepping on each other's toes or needing to share the same config. It's something that varies depending on execution context such as current working directory.

The way I am trying to approach this is, I acknowledge, a completely different way of thinking to how most systems are setup today, but I think it's excellent in terms of robustness and repeatability, and a minor improvement to security (because you get some of the benefits of immutability, while still ultimately being free to configure & customize).

@the-mikedavis That's understandable, then. That would make declarative control entirely possible through the same mechanism. What's the time table on this change?

[kirawi]

The issue I linked was about your request and why it was rejected as-proposed.

[the-mikedavis]

We don't do time tables / ETAs. If you want a feature or workaround ahead of time you'll need to make the changes locally or in a fork. You can follow the issue's status for updates when it closes

[crabdancing]

I'll just fork, then. Thanks for the info.