<cole-h>
If it's fetched from the remote, then I don't see a difference between updating a hash and rev vs. updating the actual keys themselves
{^_^} has joined #home-manager
<cole-h>
(i.e. I, personally, would rather they be hardcoded than fetched)
<cole-h>
This would simplify implementation (no need to find a way to merge JSON with YAML) as well as allow users to see what the keys are being defined as without needing to go to a remote source
<blaggacao>
... the argument being that home-manager be the source of truth and probably the nix community is a better fundament than kakoune community in terms of evolution, so yes.
<blaggacao>
agree
<blaggacao>
I'll try to put a draft together in a minute, would be nice to get quick feedback as soon as I have somthing...
<cole-h>
Well
<cole-h>
I guess it would be easier to merge the two once imports are available in a release
<blaggacao>
What do you mean with that?
<cole-h>
You could fetch the keys.yml from GitHub, drop the file into ~/.config/alacritty/csi-u.yml or something, and then `import csi-u.yml` or whatever the syntax is
<cole-h>
(But that would gate the feature on a specific alacritty version which probably isn't the best idea)
<blaggacao>
Ah, I see, you mean if/once alacritty allows imports...
<cole-h>
It already does
<cole-h>
It just hasn't been in a released version yet
<blaggacao>
OK, but I think better use the nix native merge power. NOthing beats nix (or nickel in the future)
<cole-h>
And I guess I stand corrected -- it's available in 0.6.0
<blaggacao>
Don't you think nix/nickel is / will be a better choice for merging?
<cole-h>
I haven't been following it, but I don't think the merging implemented there is much different from what we already have?
<blaggacao>
I'm not too much into it, but I see the potential for things like associative merge strategies, similar to what kyaml uses in the kubernetes ecosystem. So maybe it's better to stick with cm-native merge semantics.
<blaggacao>
alacritty `imports` wouldn't be a big deal, but I feel config merging lies in the CM domain, rather than in the application domain.
<blaggacao>
I'll only implement something for alacritty, a more skilled person would need to generalize it for other terminals, if need be in the future.
<blaggacao>
Should I move it into CSIu.nix and move alacritty into a subfolder? Like to make it more easily discoverable?