When the scrollback is trimmed off the top, the y stops moving. This
would cause an assertion failure because y could be greater than the row
count! The test case tests this.
Previously, the screen clone would incidentally mark the full height as
"written" which would cause resize to create scrollback because it was
trying to preserve prior rows. A clone should not "write" any data. This
modifies the clone operation to create a screen with the correct height
but only copy data actually written.
Saw this on HN:
https://github.com/darrenstarr/VtNetCore/pull/14
I wanted to see if ghostty was vulnerable to it (it is not). But, its a
good example of a weird edge case in the wild and I wanted to make sure
it was redundantly tested. It looks like we read the "spec" (blog posts,
man pages, source of other terminal using tools, etc.) right.
This can cause a crash, and is impossible since zero-width chars are
always attached to a prior character. Word-wrapping doesn't come into
play here because this check happens prior to the wrapping.
This is configurable with `clipboard-trim-trailing-spaces`.
This also fixes a bug where debug builds would crash when copying blank
lines. This never affected release builds.
This adds support for OSC 52 -- applications can read/write the clipboard. Due to the security risk of this, the default configuration allows for writing but _not reading_. This is configurable using two new settings: `clipboard-read` and `clipboard-write` (both booleans).
The 256 color palette can now be configured with the `palette=N=HEX` format in the config. Example, Dracula:
```
foreground=#f8f8f2
background=#282a36
palette=0=#21222c
palette=8=#6272a4
palette=1=#ff5555
palette=9=#ff6e6e
palette=2=#50fa7b
palette=10=#69ff94
palette=3=#f1fa8c
palette=11=#ffffa5
palette=4=#bd93f9
palette=12=#d6acff
palette=5=#ff79c6
palette=13=#ff92df
palette=6=#8be9fd
palette=14=#a4ffff
palette=7=#f8f8f2
palette=15=#ffffff
```
