[Request] Conditional toml tables & variable substitution

[helmesjo]

Hi, and sorry in advance if there is an issue for this already (didn't find any).

TLDR

Substitution & Conditional tables:

[shell]
__enabled = "'${__os}' == 'macos'"
args = ["--login"]
program = "/opt/homebrew/bin/fish"

Not So TDLR

Going from yaml to toml was painless, though the former allowed importing other yaml files. In my case my dotfiles are setup so that it works seamlessly over linux/macos/windows (a script just symlinks the corresponding content of the os specific configs to ~).

In the case of alacritty for my dotfiles macos and windows symlinks the same alacritty.yaml, and then they have their own alacritty.local.yaml. The first line in the shared alacritty.yaml just has a line that imports it (basically just import = ["~/.config/alacritty/alacritty.local.yaml"]). Obviously repetition is gladly avoided especially for something like this, because issues are noticed at a much later moment.

Given that toml doens't support importing other tomls, it would be very convenient to have an enabled field, with alacritty supplying a small set of substitutions for perhaps the most obvious cases (OS, alacritty major/minor...) and very basic operators. In my case I just need OS, but I think it's not a bad thing to at least having something like this in place for the future. Obviously it should be kept trivial.

The example itself isn't the most interesting one since, of course, I "could" just have it in PATH. But I still think the feature is worth considering.

The syntax can be whatever works best (while still being valid toml format), and enabled can also be called whatever else that is more suitable.

All the best!

System

OS: Linux, macOS & Windows
Version: alacritty 0.13.0 (78fa4d6)
Linux/BSD: Wayland, Sway

[kchibisov]

you have imports in toml as well.

[helmesjo]

@kchibisov
Can't find anything in their docs and while searching I came across this issue where they explain why they don't want to add it.

@mojombo
I think file inclusion violates the minimalism principle TOML is striving for. I'd expect that if a host application thinks that config will become complex enough to warrant multiple files, it will implement a way to accommodate that. I also really don't want to open the security can-of-worms that comes with TOML files slurping in other user specified files. Thanks for the excellent discussion on this matter.

[kchibisov]

We in alacritty have imports and we had them as well before.

[helmesjo]

Great, thanks. After the initial migration I was faced with some spurious error complaining about the very same import, which threw me off a bit.