# Patches to the vendored libghostty-vt

D12 vendors libghostty-vt pinned by commit, "with a patches file if we ever
need one". This is that file.

Patches are applied **to the vendored tree in this repository**, which is
committed, so a normal `make vendor` build already has them. The `.patch`
files here exist for provenance: they say what we changed, why, and what has
to be re-applied when the vendored version is bumped. `vendor/*.vendor.json`
lists them under `patches`.

Re-vendoring is therefore: drop in the new upstream tree, apply each patch in
order, resolve anything that has moved, rebuild, run `make test`.

`contrib/vendor-check` says when that is worth doing: it compares the pin in
`vendor/*.vendor.json` against upstream and lists the commits touching the
terminal core, so watching upstream is one command rather than a browser tab.
`ship` mentions it after every release.

## 0001 — keep kitty images across a screen clear

`Terminal.eraseDisplay` called `kitty_images.delete(..., .{ .all = true })`
for both `ED 2` and `ED 3`, where the `true` means "and free the image data
for anything no longer placed".

The kitty graphics protocol separates *transmitting* an image (`a=t`, which
stores it under an id) from *placing* it (`a=p`, which puts it on screen), so
that a program can upload once and place many times — that is the whole point
of having two verbs, and the reason the delete command distinguishes `d=a`
(placements) from `d=A` (placements and data). Freeing the data on a screen
clear breaks it: any full-screen program that clears and redraws loses every
image it uploaded, and every later placement of that id draws nothing at all.

Found with a bouncing-DVD screensaver that transmits ten frames up front and
then places one per frame. It works in kitty; under us it drew nothing, and
the reason was three layers down.

The patch removes only the freeing. Placements on the cleared screen still go
— clearing the screen should clear what is on it — and the image store still
bounds itself the way it always did, with a 320MB limit and LRU eviction on
insert, which is exactly the mechanism that makes keeping them safe.

Worth sending upstream.

## 0002 — don't export weak `calloc`/`free` from the static library

`pkg/wuffs/src/main.zig` exported weak, hidden `calloc`/`free` stubs whenever
`!builtin.link_libc`. `callocStub` returns `null` unconditionally. They exist
because wuffs' generated `wuffs_foo__bar__alloc()` helpers are the only code
referencing libc's allocator, we never call them, and linker GC *usually*
strips them — the stubs are there in case it doesn't.

The comment says "weak so that any real definition wins". That holds when the
real definition comes from a shared libc, but not from a static archive: once
the linker pulls this member in for some other symbol, the weak `calloc` here
*satisfies* the reference, so it never searches `libc.a` for musl's strong
one. Every `calloc` in the consuming program then returns `NULL`, and `free`
becomes a no-op.

We only hit this in the browser demo, which is the one build that has to pass
`-Dsimd=false` (highway emits RVV intrinsics that do not compile for rv64gc),
and `GhosttyZig.zig` sets `link_libc = if (cfg.simd) true else null` — so the
demo's library is the only one of ours built without libc, and the guest links
it statically against musl. The symptom was `slosh: cannot start session main`
in the demo: the first `calloc` in `kdl.c:node_new` returned `NULL` and the
store into it faulted, which killed the session server before its socket
existed. The host build (libc linked, stubs never exported) was unaffected,
which is why every test on this machine passed.

The patch adds `and builtin.output_mode == .Exe`. The stubs still do their job
in a final link with no libc, and a library — whose consumer is the thing that
owns the choice of allocator — no longer interposes on it. `web/demo/boot-check`
is the regression test; it caught this in twenty seconds once it was run.

Worth sending upstream.