Fixes#1403
This changes the behavior of `grapheme-width-method = unicode` to change
the default state of mode 2027 to true. Prior to this, setting this
config would force grapheme clustering regardless of mode 2027. Now,
this only sets the default and running TUI programs can disable it if
they want.
Fixes#1401
SCOSC is ambiguous with regards to DECSLRM. This commit copies the logic
of xterm: if left/right mode is enabled, then CSI S is always DECSLRM.
But if left/right mode is disabled then CSI S empty always uses SCOSC.
SCORC always works.
This codepath was not previously tested (an accident). Upon testing
this codepath its clear to see the logic was incorrect. When we have to
remove rows from our scrollback to fit new rows in the circular buffer,
we have to delete graphemes, but we were deleting them from the wrong
row offset.
For the row offset, we previously used the _active_ screen but the
proper offset is the _full_ screen. Tests verify.
Fixes#1356 correctly.
This was previously fixed by #1360 which just assigned a random
placement ID. I asked the Kitty maintainer about this and this is not
the correct logic and the spec has been updated.
When a placement ID of zero is sent, we allow multiple placements but
use an internal, non-addressable placement ID. The issue with my
previous approach was someone with knowledge of internals (or luck)
could technically address the placement. This isn't allowed.
Fixes#1356
As stated in the code, the specification itself doesn't explicitly
specify this behavior (as far as I can tell), but testing in Kitty
results in this working and I believe this is how they do it.
This ensures that the start or end x values do not get adjusted when
they are off the viewport in rectangle select.
This also includes some tests for the toViewport method.
Fixes#1339.
Fixes#1343
If a wide character is found at the right edge of a terminal screen and
can't be printed without wrapping, the wide character is ignored. This
matches xterm behavior.
The one funky behavior is with grapheme clustering enabled and VS16
emoji. For VS16, we act as if VS16 was never received. This is not
specified in any way and no other terminal handles this correctly at the
time of authoring this so we're just making this up because it seems
most sensible.
When calling resize, Ghostty should be respecting the wraparound state.
This behavior matches xterm. Note that this same bug was also found in
kitty.
Fixes: #1343
Fixes#1329
Some shells and scripts use spaces and soft-wrapping as a way to move to
the next line instead of using newline (`\n`). Line selection
(triple-click by default) considers a soft-wrapped line as a single
line, so it was selecting the prompt.
This commit makes it so line selection considers semantic prompt state
(prompt vs command output) an additional boundary condition. This
requires shell integration but will make selection behave more
expectedly.
Fixes#1099
We previously applied application keypad mode logic (`ESC=` or mode 66)
whenever it was active. However, from looking at the behavior of other
terminals (xterm and foot) it appears this isn't correct.
For xterm, application keypad mode only applies unconditionally if the
keyboard mode is VT220 (`-kt vt220`). For modern terminals, application
keypad mode is only applied if mode 1035 is disabled.
Mode 1035 is the "ignore numpad state with keypad mode" mode. It
defaults to true on terminal startup. If this is true, keypads are
always encoded in numerical mode. If this is false, the numlock state
will be respected.
Rather than immediately converting a color palette index into an RGB
value for a cell color, when a palette color is used track the palette
color directly in the cell state and convert to an RGB value in the
renderer.
This causes palette color changes to take effect immediately instead of
only for newly drawn cells.
Fixes#1183
I'm not sure why the original logic was there. When I translated the
original test cases to shell and ran them in xterm, they did NOT match
what Ghostty expected. This updates the tests to match xterm and removes
this case. We can add back in more tests if/when we figure out under
what scenario this original logic was correct (if it ever was).
Fixes#1159
The cursor position is an "active" coordinate (defined at the top of
Screen.zig), but our resize was treating it as a "viewport" coordinate.
This adds a new configuration `grapheme-width-method` to change the
default behavior that Ghostty uses to calculate grapheme width. The
default value is `unicode` which is identical to setting mode 2027.
**IMPORTANT:** This changes the default Ghostty behavior to be fully
grapheme-aware including ZWJs, VS15, VS16. This may cause issues with
some legacy programs and shells.
I've changed my mind that this should become the default because enough
people use emojis now that I've found in the beta program there are more
issues reported about "incorrect emoji width" than any possibly desync
issues. We'll see.
For legacy programs, this can still be set to `grapheme-width-method =
wcswidth`.
