feat(zed): add Go-based module pipeline, cached generation, and variant support

[yukazakiri]

Summary

This PR moves Zed theme generation into the same module/target flow used by the rest of iNiR theming, and switches Zed generation to a Go implementation.

It also improves reliability and speed when wallpapers change by avoiding unnecessary regenerations and handling concurrent runs safely.

What Changed

• Added a dedicated Zed module: scripts/colors/modules/31-zed.sh
• Added Zed target metadata: scripts/colors/targets/zed.json
• Wired the editors module to include Zed module flow: scripts/colors/modules/30-editors.sh
• Added a Go theme generator: scripts/colors/zed_themegen/main.go
• Updated scripts/colors/targets/editors.json and .gitignore for integration/runtime artifacts

New Theme Output

The generator now writes all of these in one file:

• iNiR Dark
• iNiR Light
• iNiR Borderless Dark
• iNiR Borderless Light
• iNiR-alt Dark
• iNiR-alt Light

Logic Behind The Implementation

Quick breakdown of the new flow:

1. 31-zed.sh runs only when Zed theming is enabled and Zed is installed.
2. It builds an input signature from:
   • material_colors.scss
   • palette.json / colors.json
   • terminal.json
   • dots/.config/matugen/templates/zed-colors.json
   • scripts/colors/zed_themegen/main.go
3. If signature is unchanged and output already exists, generation is skipped.
4. A lock file (flock) prevents race conditions when multiple theme updates trigger at once.
5. The script prefers a cached Go binary; if build fails, it falls back to go run so updates still continue.

Inside main.go:

• Material colors are parsed with validation and fallback behavior.
• Terminal colors are merged from multiple sources (palette/SCSS/terminal JSON) with defaults as safety net.
• Alt styles are loaded from zed-colors.json template placeholders.
• Default iNiR border colors are aligned to the alt border palette for consistency.
• Borderless variants are generated by clearing border keys.
• Syntax colors now start from Zed’s One Dark/One Light defaults and blend in theme primary at a fixed 50% mix so syntax keeps familiar token contrast while still matching the active theme.

Performance: Python vs Go

I benchmarked both generators locally using the same real generated inputs:

• ~/.local/state/quickshell/user/generated/material_colors.scss
• ~/.local/state/quickshell/user/generated/palette.json
• ~/.local/state/quickshell/user/generated/terminal.json
• dots/.config/matugen/templates/zed-colors.json

Method:

• 5 warmup runs + 50 measured runs each
• Same output path in /tmp
• Go benchmark used the built binary (/tmp/inir-zed-themegen)
• Python benchmark called scripts/colors/zed/theme_generator.py via python3

Results (lower is better):

• Go: avg 3.72 ms, median 3.50 ms, p95 4 ms
• Python: avg 23.16 ms, median 23.00 ms, p95 26 ms

Observed speedup:

• ~6.2x faster on average
• ~6.6x faster on median

One-time build cost:

• Cold build (new Go cache): 2456 ms
• Warm build: 110 ms

So the tradeoff is: first compile can take a moment, but steady-state generation is much faster, and with input-signature skip logic we avoid unnecessary runs entirely when nothing changed.

Why This Approach

• Keeps Zed integrated with iNiR’s module/target architecture instead of a one-off path.
• Avoids full regenerate/write loops when nothing changed.
• Handles rapid wallpaper switches more gracefully.
• Keeps syntax readable and visually coherent with the active theme.
• Gives clearly better steady-state performance than the Python generator.

Testing

Steps to verify this works:

1. Run wallpaper changes repeatedly and confirm no go.mod file not found errors in logs.
2. Confirm ~/.config/zed/themes/ii-theme.json updates only when inputs change.
3. Open Zed and verify all six variants are available and switchable.
4. Verify syntax tokens remain distinct while still theme-tinted.
5. Verify borderless variants have transparent/no focused borders.

Checklist

• Tested on Niri (or Hyprland if applicable)
• Tested both ii and waffle families for UI changes
• Tested material, aurora, and inir styles for ii changes
• No hardcoded values (colors, fonts, durations use design tokens)
• Config changes synced in Config.qml and defaults/config.json
• Config access uses optional chaining: Config.options?.section?.option ?? default
• IPC functions have explicit return types (: void, : string, etc.)
• Shell restarted after changes: inir restart
• Logs checked for errors: inir logs
• Lazy-loaded components tested (Settings, overlays)
• No console errors or warnings

Related

Closes #
Fixes #

[orcusforyou]

yayy