This PR updates `uucode` to v0.2.0, with several new Unicode files being
parsed, various fixes (not affecting Ghostty), `wcwidth` grapheme
support, code point iteration, and finally an upgrade to Unicode 17. As
far as this impacting Ghostty, the Unicode 17 upgrade is the biggest
change, and even that is relatively minor.
31655fba3c...v0.2.0
The only needed change to the configuration is to revert `prepend`
characters to being non-zero width for Ghostty. See the comment.
No AI was used except to check the grammar of the comment. AI was used a
bit in the `uucode` changes, but mostly done by hand and closely
reviewed when used.
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.
I mostly did this to familiarize myself with the codebase and figured it
doesn't hurt to cover this with tests if I add more in this area,
despite receiving indirect coverage elsewhere.
From #10554
> I can see there being space for some kind of new sequence that tells
the terminal that "hey, I want a semantic palette" or something, that is
better adjusted to themes automatically. But, I don't think we should
this by default.
> So my concrete proposal is to eliminate the inversion and bg => fg
ramp and do a more typical dark => light ramp (still taking into account
bg/fg, but keeping 16 black and 231 white). I think this is the only way
we can really make this a default on feature. I think this would address
all the negative reactions we've gotten to it.
This adds a new `palette-harmonious`, disabled by default, which allows
generated light themes to be inverted.
Apply fixes for all of the SwiftLint rules that can be automatically
fixed (`--fix`) or addressed via some minor reformatting.
Each rule is in its own commit for easier review.
