mirror of
https://github.com/ghostty-org/ghostty.git
synced 2026-04-14 11:35:48 +00:00
5008d7eb93
I mostly did this to familiarize myself with the codebase and figured it doesn't hurt to cover this with tests if more added logic in this area, despite this logic receiving indirect coverage elsewhere. [Here's my related proposal](https://github.com/ghostty-org/ghostty/discussions/10807). I gave more thought around how to expose some of these config values and their metadata in the C api to eventually drive a settings UI and was hoping for feedback before I proceed. The cleanest path forward feels like annotating config values with formal metadata around things like: supported platforms, whether or not a restart is required, presentation metadata like grouping + ordering, tolerated ranges for values, possible enum values, etc. My intent is that Swift & other consumers can enumerate potential settings values with metadata such as to drive the UI from the metadata. --- AI Disclosure: I used Codex 5.3 to help me understand how the config subsystem in zig is exposed to Swift via the C API. Codex wrote these tests; but we brainstormed on a pragmatic coverage balance and I understand how the tests work.