Add an option to specify a languages config on the CLI

[gyreas]

I'm trying out multiple PRs alongside master, all of which use the language config relevant to their version. With the paradigm shift introduced by multi-LS support, the single language config approach doesn't work anymore. Here we have two solutions (based on my use case):
i. Either edit the master config to suit the other PRs, which means I'll get an error each time I use the master build
ii. Or, edit the config to suit the master build, then the others throw the error.

A clean solution would be the ability to supply that config as a line argument like -l --language-config. This way they all default to the config in the helix dir.

(I still wonder why this wasn't the from the start cos alternate config can be specified this way)

[kirawi]

You can create a local languages.toml in .helix/ for your project

[gyreas]

Yes but you should realize that that solution is subject to the same problem as described above.
I'm talking about a global config that'll be in action even when I'm outside a project directory, like how config.toml is.

Or is there something I'm missing? 🤔

[Philipp-M]

I think most PRs, if maintained will sooner or later update/rebase to be in line with master. The multi-lsp PR unfortunately required a few (justified) breaking changes. I don't think it makes sense to handle this any different than other breaking changes. It's the reality of living on bleeding edge (master + merging a few PRs). The dust will settle at some time soon I think, and it's also (one of) the reason(s) why it was merged shortly after a release...

That said, your feature-request makes sense, since there's already a global --config CLI option. It should be easy to implement a global --languages-config (for that helix-term/src/args.rs, helix-term/src/main.rs and helix-loader/src/{config,lib}.rs is relevant, check how --config is handled). In the meantime the suggestion of @kirawi can be used as a workaround currently.

[gyreas]

Thanks for the pointers on where to tackle. I'll see what I can do. I'll take you guys suggestions.

This will remain open meanwhile.

[the-mikedavis]

We don't want to add many more CLI flags. Ideally the location of the language-config could be set in config.toml config like in #2135

[gyreas]

Hmm 🤔 that would unify the 'configs' since the config.toml file itself is supposed to init the editor which often includes initting the grammars and queries. I'll look at the surrounding issues (and PRs, if any).

Is it being worked on before I look around?

[dschrempf]

Hi! I also would love to specify the location of the languages.toml file. What was the reason for deciding against another client flag? Isn't the language.toml part of the editor configuration, and so should be either configurable on the command line, or from config.toml?

[ldelossa]

Hello.

I'm rather interested in developing this feature.

I work on some C code bases which require 8 tab widths and a whole ton of C projects which don't.
This obviously leads to the situation where I want specific configs (indent styles specifically) for a given workspace.

The existing solution is pretty good and a standard approach, drop a helix configuration directory at the root of the repository. However, this solutions always causes frictions since not many maintainers will allow you to check in a helix specific configuration directory in the repo. Work arounds for this are pretty ugly.

However, I do agree with @the-mikedavis that adding this as a flag or options may not be best.

Would the maintainers be open to "profiles" feature similar to what VSCode offers.

This does not need to be complicated. It appears that Helix already supports "config-reload".
Therefore, it could be possible to setup a directory structure such as:

~/.config/helix/profiles/super-dope-project/{language.toml,config.toml}

Helix could then discover any subdirs of 'profiles' and 'reload' the config located inside the profile directory with a 'profile' command which piggy backs off the 'reload' command.

I don't find the need for any kinda of coalescing or stacking of profiles like in VSCode, it would be good enough to just be able to write "profiles" like this, since helix configuration footprint is already small (which is great and why helix rocks).

[the-mikedavis]

That seems fairly heavy to me, I'd rather stick to what we have for now. In the long run we want to change config so that languages.toml configuration is not distinct from config.toml configuration. Ideally we would also use a more powerful language like #8675 so you could build something like that yourself.

I also work with a codebase with occasional 8-width tabs (mixed with spaces) and I have a .helix/languages.toml that I just don't check in.

[joefiorini]

@ldelossa @the-mikedavis fwiw I too use .helix/languages.toml for one of my projects. Instead of just leaving it not checked in, I added it to .git/info/exclude (assuming you use git). Now it stays out of my git status. Mentioning on the off chance either of you weren't aware of that feature.