This fixes the Nix *package* build (read: not devShell, which is not
touched) so that it builds, and also conforms to what is generally seen
for a Zig project in nixpkgs.
The highlights:
* We use a Zig 0.12 derivation that I constructed from the Zig 0.11
derivation, in addition to LLVM 17 updates found in
NixOS/nixpkgs#258614. This specifically includes the patches that
address ziglang/zig#15898, and also allows us to take advantage of the
build hooks included in the Zig toolchain there.
* We pre-download the cache using "zig build --fetch" and a fixed-output
derivation. This is similar to how the Go builders work in nixpkgs and
I could see Zig ultimately going in a similar path, given that the
fetcher part of the build system seems to be shaping up to having a Go
module system-style DX (mind you, this is a naive opinion right now).
* Finally, cleaned up the derivation so that there's no special fixups
happening outside of what is defined in the basic nixpkgs workflow.
This is similar to other Zig projects I looked at (notably River) that
seem to just include their dependencies in buildInputs and call it a
day.
One specific change that is worth noting is that this changes the build
mode from ReleaseFast to ReleaseSafe - this is the current default
within the Zig build hook in nixpkgs. If we need ReleaseFast, we'll have
to override this.
Related to #642Fixes#910
See #642 for why we want to ignore the "always" userTabbingPreference.
To do that, we'd set tabbingMode to "disallow" because we manually (in
code) handled it all.
Unfortunately, setting the tabbingMode to "disallow" introduce #910. I
still believe this is a macOS bug at heart, so I'm going to submit an
Apple Feedback item for it. However, I've found a workaround which I
also feel is the better solution, implemented here.
Instead of setting tabbingMode to "disallow" I now detect if we're in
the scenario where the user has their system tabbing preference set to
"always". In that case, we detect if the new window has been
automatically put into a tab group by macOS, and if so we remove it.
This all happens in the `windowDidLoad` controller callback. At this
phase, our Ghostty-managed windows should NEVER be in a tab group,
because "new tab" adds them to a tab _after_. So we can be certain that
if we're already in a tab group it was from the macOS system setting.
This happens to fix#910.
