feat(wrapperModules.ghostty): init

[TrustworthyAdult]

Settings are written to a generated Nix store config file and loaded via --config-default-files=false --config-file=<path>, so the host config is never loaded -- including on machines that already have their own Ghostty config. The host config path varies by platform: ~/.config/ghostty/config on Linux, and ~/Library/Application Support/com.mitchellh.ghostty/config on macOS.

On macOS, ghostty-bin is used by default, which is the pre-built binary distribution recommended for nix-darwin by the Ghostty installation docs.

Known limitations

• ghostty +show-config and ghostty +validate-config will show the host config rather than the generated one. Ghostty's action-mode option parsers reject --config-file, so there is no way to point them at the generated config.

• If you pass an additional --config-file flag at runtime, Ghostty merges it on top of the generated config (later files take precedence for conflicting keys).

[TrustworthyAdult]

Converted to draft — this is blocked on #548 which fixes the wlib-formatting CI crash on macOS. Once that merges I'll rebase and mark ready.

[TrustworthyAdult]

Please excuse the number of edits and CI runs on this PR. I previously thought that this PR was blocked by a CI-related change so every time I needed to test that change, I'd re-run the CI pipeline on the other PR and then rebase here.

[BirdeeHub]

#393

^ This PR might have some useful things in it for you (The last PR attempt, which ran into similar bugs in ghostty but was otherwise quite good)

[BirdeeHub]

Some changes requested to the other PR to allow

  settings.keybind = [
    "ctrl+a>-=new_split:down"
    "ctrl+a>==new_split:right"
  ];

for

keybind=ctrl+a>-=new_split:down
keybind=ctrl+a>==new_split:right

and

  settings.config-file = [
    "${./more}"
    "${./files}"
  ];

[BirdeeHub]

Suggested change

	type = lib.types.attrsOf (
	lib.types.oneOf [
	lib.types.bool
	lib.types.float
	lib.types.int
	lib.types.str
	]
	);
	type = let
	atom = lib.types.oneOf [
	lib.types.bool
	lib.types.float
	lib.types.int
	lib.types.str
	];
	in lib.types.attrsOf (lib.types.either (lib.types.listOf atom) atom);

[BirdeeHub]

Alternatively, we could use inherit (pkgs.formats.keyValue { listsAsDuplicateKeys = true; }) type;

Or even add https://github.com/NixOS/nixpkgs/blob/2bc4da5851acf09c933e582394e122fb5402ea4e/pkgs/pkgs-lib/formats.nix#L417-L446 <-- the type to wlib.types (because they have neglected to give us a way to use it without grabbing it from pkgs) or open a PR for them to move it in nixpkgs (If you do that, give this PR a shoutout too! That is our wlib.types.structuredValueWith type)

[TrustworthyAdult]

Applied both suggestions: listsAsDuplicateKeys = true in the generator, and the type updated to attrsOf (either (listOf atom) atom). I also updated the example and tests to demonstrate the duplicate-key behaviour with a keybind list.

I went with the explicit either union rather than inheriting from pkgs.formats.keyValue to keep the type out of pkgs. If your nixpkgs PR (#516798) lands and that type becomes available in lib without needing a pkgs instance, happy to consolidate here at that point.

[BirdeeHub]

#516798

This is actually a different type entirely, I was just mentioning it.

[TrustworthyAdult]

@BirdeeHub ah sorry I'll look in more detail tomorrow and get back to you

[BirdeeHub]

I think I am OK with the intercepting of those args as a workaround for now. They have at least acknowledged the issue, and people could set argv0type themselves if they don't want it.

One question, what happened to our filesToPatch we had there before? Are they not necessary due to using ghostty-bin on mac? Or is there some reason why they were removed?

I think other than that this is good though, but I am curious about where that went, because you had them in your original version of the PR.

Once we add those back, or you explain why we don't need them anymore, I guess we should probably just go ahead and merge it rather than waiting around for ghostty to fix the bug, its been long enough...