Previously, the property binding created in `Surface.bindIsSplit` would
get freed automatically when the source object (the SplitTree widget)
got finalized. A subsequent call to `bindIsSplit` could then cause a
crash by using the stale pointer to the binding. This bug could e.g. be
triggered by dragging the surface from a single-surface tab to another
tab.
We now create an extra reference to the binding object so that Surface
essentially owns the binding and is responsible for freeing it.
Updated the binding in `SurfaceScrolledWindow` to use the same pattern.
That one was probably fine, because the binding is only created once,
but let's be safe.
Erasing a wrapped wide character at the start of a row (`ECH` or `DCH`)
also clears the spacer head it left at the end of the previous row, but
that row was never marked dirty. With both rows visible, an incremental
render kept the stale spacer head on screen until something unrelated
redrew that row.
The clearing happens in the row-start branch of `splitCellBoundary`.
`clearCells` doesn't do dirty tracking, and both callers only mark the
cursor row, so mark the previous row at the point it's mutated.
The added dirty assertions fail without the fix.
## AI Disclaimer
Claude did the heavy lifting - identifying the root cause, generating
code and description. I reviewed and iterated on it to move around and
tweak tests, comments and reduce verboseness. Verified the end user
visible behaviour improvement with a script that coloured the wide
character, which made the stale rendering visible until a switch to the
alt screen and back cleared it it.
Erasing a wrapped wide character at the start of a row (ECH or DCH)
also clears the spacer head it left at the end of the previous row,
but that row was never marked dirty. With both rows visible, an
incremental render kept the stale spacer head on screen until
something unrelated redrew that row.
The clearing happens in the row-start branch of splitCellBoundary.
clearCells doesn't do dirty tracking, and both callers only mark
the cursor row, so mark the previous row at the point it's mutated.
The added dirty assertions fail without the fix.
Discussion #14048
Directory URLs no longer export a trailing slash through PWD, which
keeps zsh's %1~ prompt expansion from resolving to an empty string.
A shared URL helper removes trailing separators while preserving the
filesystem root and percent-decoding behavior. Tests cover normal,
repeated, encoded, and root paths.
Discussion #14048
Directory URLs no longer export a trailing slash through PWD, which
keeps zsh's %1~ prompt expansion from resolving to an empty string.
A shared URL helper removes trailing separators while preserving the
filesystem root and percent-decoding behavior. Tests cover normal,
repeated, encoded, and root paths.
`send key` only works for control keys like `enter` currently; this adds
(fixes) the support for other keys listed as available. Found by
@paaloeye in #13180
The core of this fix is relying on `UCKeyTranslate` to get the
corresponding character and code point from a key code using
`KeyboardLayout.character(for:modifiers:)`.
ScriptKeyEventCommand now respects `macos-option-as-alt`, and attach
`text`, `unshifted_codepoint` and `consumed_mods` under the same
condition as a manual input events like in `performKeyEquivalent` and
`localEventKeyDown`.
## AI Disclosure
Claude did the heavy lifting, I reviewed and rephrased some of the
comments it generated. And ofc reviewed and tested myself.
Use a bounded 512-byte stack fallback for complete-snapshot record
scratch. Small records avoid heap growth while larger records continue
through the heap allocator.
This usually means 2 fewer allocations per encode, resulting in a small
performance improvement in a local benchmark:
| Workload | `main` median | Branch median | Change |
|---|---:|---:|---:|
| Empty, 50k encodes | 135.06 ms | 130.76 ms | **3.2% faster** |
| 1 MiB ASCII, 500 encodes | 280.75 ms | 281.25 ms | **0.2% slower**,
within noise |
| 1 MiB styled, 200 encodes | 1,023.02 ms | 996.32 ms | **2.6% faster**
|
Bumps
[hustcer/milestone-action](https://github.com/hustcer/milestone-action)
from 3.1 to 3.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/hustcer/milestone-action/releases">hustcer/milestone-action's
releases</a>.</em></p>
<blockquote>
<h2>v3.2</h2>
<h2>[3.2] - 2026-08-25</h2>
<h3>Bug Fixes</h3>
<ul>
<li>Harden action inputs and make GraphQL file lookup path-independent
(<a
href="https://redirect.github.com/hustcer/milestone-action/issues/168">#168</a>)</li>
<li>Look up milestones by title across all states with pagination (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/170">#170</a>)</li>
<li>Guard GITHUB_OUTPUT, surface GraphQL errors and tighten is-int (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/172">#172</a>)</li>
<li>Require title for create action and sync stale docs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/174">#174</a>)</li>
<li>Send milestone fields as raw strings and harden action inputs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/176">#176</a>)</li>
</ul>
<h3>Deps</h3>
<ul>
<li>Upgrade hustcer/setup-nu to v3.25 & Nu to 0.113.1</li>
<li>Upgrade hustcer/setup-nu to v3.27 and Nu to 0.115</li>
<li>Upgrade Nu to 0.115.1</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/hustcer/milestone-action/blob/main/CHANGELOG.md">hustcer/milestone-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<h2>[3.2] - 2026-08-25</h2>
<h3>Bug Fixes</h3>
<ul>
<li>Harden action inputs and make GraphQL file lookup path-independent
(<a
href="https://redirect.github.com/hustcer/milestone-action/issues/168">#168</a>)</li>
<li>Look up milestones by title across all states with pagination (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/170">#170</a>)</li>
<li>Guard GITHUB_OUTPUT, surface GraphQL errors and tighten is-int (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/172">#172</a>)</li>
<li>Require title for create action and sync stale docs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/174">#174</a>)</li>
<li>Send milestone fields as raw strings and harden action inputs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/176">#176</a>)</li>
</ul>
<h3>Deps</h3>
<ul>
<li>Upgrade hustcer/setup-nu to v3.25 & Nu to 0.113.1</li>
<li>Upgrade hustcer/setup-nu to v3.27 and Nu to 0.115</li>
<li>Upgrade Nu to 0.115.1</li>
</ul>
<h2>[3.1] - 2026-01-23</h2>
<h3>Documentation</h3>
<ul>
<li>Update milestone-action version in README (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/162">#162</a>)</li>
</ul>
<h3>Features</h3>
<ul>
<li>Break before sleep when milestone found</li>
</ul>
<h3>Miscellaneous Tasks</h3>
<ul>
<li>Update README.md (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/166">#166</a>)</li>
</ul>
<h3>Deps</h3>
<ul>
<li>Update Nu to 0.109.1</li>
<li>Update Nushell to 0.110.0 (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/167">#167</a>)</li>
<li>Upgrade hustcer/setup-nu to v3.22</li>
</ul>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<h2>[3.0] - 2025-10-26</h2>
<p>This release introduces changes that may impact some users. If the
action fails due to insufficient permissions, please add the
<code>issues: write</code> and <code>pull-requests: write</code>
permissions to your workflow. Additionally, the API for binding
milestones has been modified. Due to these changes, the major version
has been incremented to 3.</p>
<h3>Bug Fixes</h3>
<ul>
<li>Try to fix GitHub Projects (classic) deprecation warning by using
REST API instead of GraphQL (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/157">#157</a>)</li>
<li>Fix "Resource not accessible by integration" error for
issue milestone binding by adding <code>issues: write</code>
permission</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="2f38355153"><code>2f38355</code></a>
Bump to v3.2</li>
<li><a
href="90d6122217"><code>90d6122</code></a>
deps: Upgrade Nu to 0.115.1</li>
<li><a
href="e587063f37"><code>e587063</code></a>
fix: Send milestone fields as raw strings and harden action inputs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/176">#176</a>)</li>
<li><a
href="cc2b756fd4"><code>cc2b756</code></a>
fix: Require title for create action and sync stale docs (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/174">#174</a>)</li>
<li><a
href="f8cedae0c1"><code>f8cedae</code></a>
fix: Guard GITHUB_OUTPUT, surface GraphQL errors and tighten is-int (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/172">#172</a>)</li>
<li><a
href="b57a2e26d7"><code>b57a2e2</code></a>
fix: Look up milestones by title across all states with pagination (<a
href="https://redirect.github.com/hustcer/milestone-action/issues/170">#170</a>)</li>
<li><a
href="3ba8f40c95"><code>3ba8f40</code></a>
fix: Harden action inputs and make GraphQL file lookup path-independent
(<a
href="https://redirect.github.com/hustcer/milestone-action/issues/168">#168</a>)</li>
<li><a
href="1e6a3fcc55"><code>1e6a3fc</code></a>
deps: Upgrade hustcer/setup-nu to v3.27 and Nu to 0.115</li>
<li><a
href="9131595492"><code>9131595</code></a>
deps: Upgrade hustcer/setup-nu to v3.25 & Nu to 0.113.1</li>
<li>See full diff in <a
href="ebed8d5daa...2f38355153">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
#14033
Pause the CVDisplayLink when there isn't any real work to do.
Start the link after updateFrame rebuilds cells, keep it running while
cell changes or animations remain pending, and resync it from the
no-redraw path to sleep it again.
I also did some benchmark to measure the cost of starting/stopping the
display link since this includes a lot more of that and I found that a
continuously running link used 29 to 35 us of CPU per callback, while
starting and stopping it for every frame used 103 to 121 us. So, in some
pathological case this can be worse, but its still microseconds, and in
the normal case this helps Ghostty sleep a lot more.
#14033
Pause the CVDisplayLink when there isn't any real work to do.
Start the link after updateFrame rebuilds cells, keep it running while
cell changes or animations remain pending, and resync it from the
no-redraw path to sleep it again.
I also did some benchmark to measure the cost of starting/stopping the
display link since this includes a lot more of that and I found that
a continuously running link used 29 to 35 us of CPU per callback, while
starting and stopping it for every frame used 103 to 121 us. So, in some
pathological case this can be worse, but its still microseconds, and in
the normal case this helps Ghostty sleep a lot more.
Co-authored-by: Jesse Miller <jmiller@jmiller.com>
Drop UTF-8 decoded C1 controls entirely. This matches xterm's default
behavior which is our standard policy (but note it diverges from libvte
which executes them). There isn't really any standard I could find
around this.
The ground state UTF-8 fast paths (both the scalar decoder and the
batched SIMD path) previously treated decoded codepoints C1 control
codepoints as normal UTF-8 text and routed them to print.
Drop UTF-8 decoded C1 controls entirely. This matches xterm's default
behavior which is our standard policy (but note it diverges from libvte
which executes them). There isn't really any standard I could find
around this.
The ground state UTF-8 fast paths (both the scalar decoder and the
batched SIMD path) previously treated decoded codepoints C1 control
codepoints as normal UTF-8 text and routed them to print.
Fixes#14021
The ground state UTF-8 fast paths only classified 0x00-0x0F plus 0x1B
(escape) as C0 controls. The remaining C0 bytes (0x10-0x1A, 0x1C-0x1F)
were decoded as ordinary codepoints and routed to print as if they were
text.
This resulted in incorrect grids but also very weird font fallback, e.g.
U+0014 would find CJK fonts.
This commit fixes this by routing every ground state C0 byte except ESC
to execute as it should be.
Fixes#14021
The ground state UTF-8 fast paths only classified 0x00-0x0F plus 0x1B (escape)
as C0 controls. The remaining C0 bytes (0x10-0x1A, 0x1C-0x1F) were decoded
as ordinary codepoints and routed to print as if they were text.
This resulted in incorrect grids but also very weird font fallback, e.g.
U+0014 would find CJK fonts.
This commit fixes this by routing every ground state C0 byte except ESC to
execute as it should be.
Use a bounded 512-byte stack fallback for complete-snapshot record
scratch. Small records avoid heap growth while larger records continue
through the heap allocator.
Ref #12034
This commit releases many GPU resources when a surface becomes invisible
and rebuilds it on the next draw. I don't say "all" because there are
still some things we can improve on (Kitty images).
We previously held onto all GPU resources for the lifetime of the
surface regardless of its visibility state. This is 3x (for
triple-buffering): screen render targets, uniform/cell/custom shader
buffers, font textures, and more.
Measured on macOS (Metal):
| Measurement (1 visible + 20 hidden tabs) | Before | After |
|---------------------------------------------|-----------|---------|
| Tracked GPU allocations (steady state) | 384.6 MiB | 18.3 MiB |
| `MTLDevice.currentAllocatedSize` | 393.3 MiB | 19.7 MiB |
| `footprint` IOSurface (dirty) | 309 MB | 15 MB |
| Swap chain rebuild on unhide (42 tab switches) | n/a | avg 0.43 ms,
max 0.55 ms |
As you can see, importantly, swap chain rebuild is fast: 0.43ms average.
That means that the rebuild is imperceptible and happens well within a
frame draw time.
This is macOS only, but most of the work was in the generic renderer.
GTK only needs to call `releaseGpuResources` when it becomes invisible
to get the same benefits. I didn't have my VM handy to test this yet so
I didn't include it.
Ref #12034
This commit releases many GPU resources when a surface becomes invisible and
rebuilds it on the next draw. I don't say "all" because there are still
some things we can improve on (Kitty images).
We previously held onto all GPU resources for the lifetime of the surface
regardless of its visibility state. This is 3x (for triple-buffering):
screen render targets, uniform/cell/custom shader buffers, font textures,
and more.
Measured on macOS (Metal):
| Measurement (1 visible + 20 hidden tabs) | Before | After |
|---------------------------------------------|-----------|---------|
| Tracked GPU allocations (steady state) | 384.6 MiB | 18.3 MiB |
| `MTLDevice.currentAllocatedSize` | 393.3 MiB | 19.7 MiB |
| `footprint` IOSurface (dirty) | 309 MB | 15 MB |
| Swap chain rebuild on unhide (42 switches) | n/a | avg 0.43 ms, max 0.55 ms |
As you can see, importantly, swap chain rebuild is fast: 0.43ms average.
That means that the rebuild is imperceptible and happens well within
a frame draw time.
This is macOS only, but most of the work was in the generic renderer.
GTK only needs to call `releaseGpuResources` when it becomes invisible
to get the same benefits. I didn't have my VM handy to test this yet so
I didn't include it.
Refs #11216
The dcs_passthrough state only forwarded bytes 0x00-0x7E to the DCS
handler. Bytes 0x80-0x9F hit the "anywhere" C1 transitions and exited
the string, while 0xA0-0xFF fell through to the default transition and
were silently dropped. **This breaks any DCS payload carrying UTF-8. **
A continuation byte in the C1 range terminates or corrupts the string:
"Ü" is 0xC3 0x9C, so the 0xC3 is dropped and the 0x9C acts as 8-bit ST,
ending the DCS mid-character.
Also, a payload byte such as 0x9B (second byte of "Û") transitions to
csi_entry, so the remainder of the payload executes as a live control
sequence. This is a prerequisite for tmux control mode (#1935), whose
%output notifications carry raw UTF-8 pane content.
Fix this in the parse table only: override 0x80-0xFF in dcs_passthrough
to put and in dcs_ignore to ignore, exactly how osc_string already
claims 0x20-0xFF (including 0x9C) as data. This deviates from the
vt100.net state machine
(https://vt100.net/emu/dec_ansi_parser) deliberately and includes 0x9C:
a raw 0x9C is indistinguishable from a UTF-8 continuation byte, and we
don't honor 8-bit C1 controls in the ground state either.
The demo code shown in the `+list-themes` theme preview was stale from
before the Zig 0.16 migration (context: #12228). It referenced
`std.Io.getStdOut().writer()`, which never existed in any Zig release,
and `pub fn main() !void`. This rewrites the rendered sample to valid
Zig 0.16 idioms:
```zig
const std = @import("std");
pub fn main(init: std.process.Init) !void {
var buf: [1024]u8 = undefined;
var stdout = std.Io.File.stdout().writer(init.io, &buf);
const w = &stdout.interface;
var i: usize = 1;
while (i <= 16) : (i += 1) {
if (i % 15 == 0) {
try w.writeAll("ZiggZagg\n");
} else if (i % 3 == 0) {
try w.writeAll("Zigg\n");
} else if (i % 5 == 0) {
try w.writeAll("Zagg\n");
} else {
try w.print("{d}\n", .{i});
}
}
try w.flush();
}
```
The gutter line numbers, row offsets, and child window height were
renumbered to match, and the zig version shown in the demo prompt line
was updated from v0.13.0 to v0.16.0.
Refs #11216
The dcs_passthrough state only forwarded bytes 0x00-0x7E to the DCS
handler. Bytes 0x80-0x9F hit the "anywhere" C1 transitions and exited
the string, while 0xA0-0xFF fell through to the default transition and
were silently dropped. **This breaks any DCS payload carrying UTF-8. **
A continuation byte in the C1 range terminates or corrupts the string:
"Ü" is 0xC3 0x9C, so the 0xC3 is dropped and the 0x9C acts as 8-bit ST,
ending the DCS mid-character.
Also, a payload byte such as 0x9B (second byte of "Û") transitions to
csi_entry, so the remainder of the payload executes as a live control sequence.
This is a prerequisite for tmux control mode (#1935), whose %output
notifications carry raw UTF-8 pane content.
Fix this in the parse table only: override 0x80-0xFF in
dcs_passthrough to put and in dcs_ignore to ignore, exactly how
osc_string already claims 0x20-0xFF (including 0x9C) as data. This
deviates from the vt100.net state machine
(https://vt100.net/emu/dec_ansi_parser) deliberately and includes
0x9C: a raw 0x9C is indistinguishable from a UTF-8 continuation byte,
and we don't honor 8-bit C1 controls in the ground state either.
The Kitty clipboard protocol now specifies base64 handling: All OSC 5522
payloads and the base64 metadata values (mime, name, pw) use strict RFC
4648 with the standard alphabet. Characters outside the alphabet
(including whitespace) and incorrect padding must be rejected, never
silently skipped.
For wdata payloads for one MIME type, the base64 stream can be split at
arbitrary packet boundaries and only the concatenation must be correctly
padded.
Simdutf has a strict mode for base64 so we got this for free. Benchmarks
to be safe:
| Decoder | Time | Throughput |
|-------------------------------|-------|------------|
| permissive (previous) | 99ms | 10.8 GB/s |
| strict | 97ms | 11.1 GB/s |
| strict, streaming 4KiB chunks | 102ms | 10.5 GB/s |
| strict w/ separate scan pass | 143ms | 7.5 GB/s |
| std.base64 scalar | 234ms | 4.6 GB/s |
Spec changes upstream:
479872838fhttps://sw.kovidgoyal.net/kitty/clipboard/#encoding-of-payloads
Update nixpkgs-unstable to pick up fontconfig 2.18. Currently we are
linking against 2.17 and you get errors like this on standard error when
using config files meant for fontconfig 2.18:
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 20:
invalid constant used :
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 23:
invalid constant used : monospace
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 42:
invalid attribute 'xsi:nil'
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 43:
invalid constant used :
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 46:
invalid constant used : sans-serif
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 68:
invalid attribute 'xsi:nil'
Fontconfig warning: "/etc/fonts/conf.d/48-guessfamily.conf", line 69:
invalid constant used :
The Kitty clipboard protocol now specifies base64 handling:
All OSC 5522 payloads and the base64 metadata values (mime, name, pw)
use strict RFC 4648 with the standard alphabet. Characters outside
the alphabet (including whitespace) and incorrect padding must be
rejected, never silently skipped.
For wdata payloads for one MIME type, the base64 stream can be split
at arbitrary packet boundaries and only the concatenation must be
correctly padded.
Simdutf has a strict mode for base64 so we got this for free.
Benchmarks to be safe:
| Decoder | Time | Throughput |
|-------------------------------|-------|------------|
| permissive (previous) | 99ms | 10.8 GB/s |
| strict | 97ms | 11.1 GB/s |
| strict, streaming 4KiB chunks | 102ms | 10.5 GB/s |
| strict w/ separate scan pass | 143ms | 7.5 GB/s |
| std.base64 scalar | 234ms | 4.6 GB/s |
Spec changes upstream:
479872838fhttps://sw.kovidgoyal.net/kitty/clipboard/#encoding-of-payloads
