idea: pass through iterm2-color-schemes

[colemickens]

Hi!

I've had my own little nix-rice (that I think I forked from somewhere else?) that utilizes iterm2-color-schemes.

I'm also seeing that iterm2-color-schemes seems to automatically handle munging each theme into the format needed for various terminals/applications.

Are you open to me extending this repo (so I can delete my stagnating whatever repo) with a non-flake flake input for iterm2-color-schemes along with maybe some helpful functions to munge the toml/yaml back to a nix representation that users can then trivially add?

It should allow for niceties like single-update to change themes across all terminal emulators, etc. It's maybe "inelegant" in that iterm2-color-schemes is "duplicating" the color info for each application, but it also removes the entire headache of each terminal having slightly different naming, or extra color options, etc.

https://github.com/mbadolato/iTerm2-Color-Schemes/tree/master has wezterm, alacritty, rio, and I'm sure something that is foot-compatible which covers all the term emus I'm tinkering with.

[bertof]

Hi, so you're willing to add iterm2-color-schemes to the inputs and to support it as i'm now doing with kitty's themes? If that's so that's a great idea that I fully support it. The only critical point would be to use the same names and structure of the standard palette, so it's easy to use them in established dotfiles.

If, instead, the change is to also add transformers/builders from palettes to the specific terminal/app configurations, we already have a widely used solution, home-manager, that handles configuration files. So the best approach is probably to interface with that. But that adds a bit of extra maintenance work to this project as home-manager may change their modules and some apps are not supported yet (i.e. I use terminator as a backup terminal in case kitty has some problems.).

Either way those two features would be super cool to have and if you have time for this I'd be happy to merge your work in this repo.

[colemickens]

As I thought about it more, I think that regardless of whether it makes sense to add iterm2-color-schemes, the transformer approach is better than what I was sort of originally thinking. I was thinking that I could re-use the rendered/translated themes in iterm2-color-schemes, since they seem to duplicate/templatize the themes ahead-of-time for various terminals.

That sort of doesn't sit right with me, and also makes it had to re-use the colorschemes in the context of home-manager, which is certainly my end goal. And arbitrarily limits to what terms iterm2-color-schemes happens to support at any given type.

It feels like, for the most part, most of the terminal emulators in home-manager mostly offer an arbitrary attrset settings field.

So, what I'm imagining now is some transformer functions, in this repo:

1. (optionally) can consume iterm2 color schemes, hopefully there's a json format that has a super-set of all colors used by any term emu, and maybe parse and use that as the "internal" nix representation.
2. an set of transformers that knows how to take that internal representation and convert it to the appropriate type of attributes, that get "passed through" home-manager->termemu->settings into the final term-specific config file

I think this shouldn't expose us to too much churn from the home-manager perspective, ultimately, given how the settings attribute is handled and just converted.

---

It seems like you have some of this in the example/ directory, but slightly differently. I'll tinker around with this a bit and see what I come up with...

[bertof]

Yes, that is exactly my point. Feel free to add iterm2-color-schemes as an input, a new source of pre-made themes surely is a nice to have. Regarding the transformers, at the moment I'm using something custom for my dotfiles, ranging from a simple set merge and naming conversions , up to rewriting the whole configuration file. It really depends on the level of support provided by home-manager. The examples in the example/ folder might be a bit outdated, again because of home-manager changes; the ones on the GitLab repo are up to date and working.