Fixes#5022
The CSI SGR sequence (CSI m) is unique in that its the only CSI sequence
that allows colons as delimiters between some parameters, and the colon
vs. semicolon changes the semantics of the parameters.
Previously, Ghostty assumed that an SGR sequence was either all colons
or all semicolons, and would change its behavior based on the first
delimiter it encountered.
This is incorrect. It is perfectly valid for an SGR sequence to have
both colons and semicolons as delimiters. For example, Kakoune sends
the following:
;4:3;38;2;175;175;215;58:2::190:80:70m
This is equivalent to:
- unset (0)
- curly underline (4:3)
- foreground color (38;2;175;175;215)
- underline color (58:2::190:80:70)
This commit changes the behavior of Ghostty to track the delimiter per
parameter, rather than per sequence. It also updates the SGR parser to
be more robust and handle the various edge cases that can occur. Tests
were added for the new cases.
Related to #4485
This commit matches ConEmu's parsing logic[^1] more faithfully. For any
substate that requires a progress, ConEmu parses so long as there is a
number and then just ignores the rest.
For substates that don't require a progress, ConEmu literally ignores
everything after the state.
Tests cover both.
[^1]: 740b09c363/src/ConEmuCD/ConAnsiImpl.cpp (L2264)
Extracted from #3110
Initial fix is relatively basic, and catching it with a test only
required a little bit of extra scrutiny of the cursor state after one of
the tests that we already had.
However, the fix revealed faulty dirty tracking logic throughout the
`cursorScrollAbove` function (and therefore bad results that were being
tested for when they should not have been). I've ended up clarifying
things, fixing the asserted dirty states in all the `cursorScrollAbove`
tests, and then finally implementing another very trivial fix that
catches the mistake.
Fixing the dirty tracking is really just an exercise in correctness
though, since when the scroll happens it inherently invalidates the
viewport, and therefore will trigger a full rebuild in the renderer...
unless, I guess, another operation is performed that cancels things out
and results in the viewport pin being in the same place as the previous
render, but that seems an exceptionally difficult scenario to make
happen on purpose much less accidentally.
This PR is almost entirely changes to comments and tests, there are only
2 lines of real code it changes, the one added to the start of
`cursorScrollAbove` and the one modified at the start of
`cursorScrollAboveRotate`. I believe these changes are entirely safe. (I
wonder if they might have a bad effect on our `vtebench` scrolling
performance though...)
Accounts for improved behavior due to prior memory corruption fix for
`cursorScrollAboveRotate` and reveals a new problem in a different
`cursorScrollAbove` sub-function.
Unless it's guaranteed that the new pin is in the same page as the old
one, `cursor.page_pin` should only be updated through `cursorChangePin`,
not directly.
We call `cursorChangePin` which may invalidate the provided pin if it
needs to adjust the page capacity, and as such we should consider the
pin we pass in to it invalid afterwards, and access it through cursor
instead.
Fixes#3119
Supersedes #3099
ConEmu and iTerm2 both use OSC 9 to implement different things. iTerm2
uses it to implement desktop notifications, while ConEmu uses it to
implement various OS commands.
Ghostty has supported iTerm2 OSC 9 for a while, but it didn't (and
doesn't) support ConEmu OSC 9. This means that if a program tries to
send a ConEmu OSC 9 to Ghostty, it will turn into a desktop
notification.
This commit adds parsing for ConEmu OSC 9 progress reports. This means
that these specific syntaxes can never be desktop notifications, but
they're quite strange to be desktop notifications anyway so this should
be an okay tradeoff.
This doesn't actually _do anything with the progress reports_, it just
parses them so that they don't turn into desktop notifications.
cc @Jan200101
Fixes#3119
ConEmu and iTerm2 both use OSC 9 to implement different things. iTerm2
uses it to implement desktop notifications, while ConEmu uses it to
implement various OS commands.
Ghostty has supported iTerm2 OSC 9 for a while, but it didn't (and
doesn't) support ConEmu OSC 9. This means that if a program tries to
send a ConEmu OSC 9 to Ghostty, it will turn into a desktop notification.
This commit adds parsing for ConEmu OSC 9 progress reports. This means
that these specific syntaxes can never be desktop notifications, but
they're quite strange to be desktop notifications anyway so this should
be an okay tradeoff.
This doesn't actually _do anything with the progress reports_, it just
parses them so that they don't turn into desktop notifications.
Back out "perf(styles): greatly improve style.hash performance"
This backs out commit 3bfe4cd25ca7a5ae4d4084818b86ada9236b3bb5, but
keeps the hash algorithm as XxHash3 which showed improvements in
performance.
By switching to one-shot hashing of the raw bytes of the struct with
XxHash3 instead of using `autoHash` with Wyhash, a performance gain of
around 20% can be observed in DOOM-fire-zig.
Fixes#2841
We were incorrectly applying the start/end x offset for the first/last
row of every single page. If a selection spanned multiple pages this
would trim data incorrectly.
Unit test updated to cover this case.
Fixes#2497
While investigating the issue I added an integrity check that found a
problem hiding in the insert logic that was unrelated- in fixing that I
greatly simplified the insert logic.
It turns out that #2497 is ultimately just a case of bad luck,
pathological inputs that result in very non-uniform hashes so the
clustering overwhelms things. The solution was just to add a check and
claim we're out of memory.
I tried adding an entropy folding function to fix the hash a little but
it had a measurable negative impact on performance and isn't necessary
so I've not included it here. Currently there's an open PR to Zig to
[add RapidHash](https://github.com/ziglang/zig/pull/22085), which is the
successor to Wyhash and apparently has much better statistical
characteristics on top of being faster. I imagine it will land in time
for 0.14 so whenever we update to 0.14 we should probably switch our
standard hash function to RapidHash, which I imagine should yield
improvements across the board.
Using the AutoHasher may also be not the best idea, I may explore ways
to improve how we generate our style hashes in the future.
Fixes#2958
The y was alround bounded but we allowed any x value and assumed the
caller would handle it. This is not the case so we now check the x and
return null if it's out of bounds (same as y, which was already doing
this).
Poor hash uniformity and/or a crafted or unlucky input could cause the
bounds of the PSL stats array to be exceeded, which caused memory
corruption (not good!) -- we avoid such cases now by returning an
OutOfMemory error if we're about to insert and there's an item with a
PSL in the last slot.
Previous logic had multiple issues that were hiding in edge cases of
edge cases with the ressurected item handling among other things; the
added assertIntegrity method finds these issues, the primary one being
an edge case where an ID is present in two different buckets.
Added more comments to explain logic in more detail and fixed a couple
little things like always using `+%` when incrementing the probe pos,
and replacing a silent return on an integrity issue that should be
impossible (`table[item.meta.bucket] != id`) with an assert.
Our semantic prompts are row-based, so the last prompt marker set on a
row "wins". In the case of at least our bash shell integration, this
means that consecutive prompt lines will all be marked as .input (OSC
133;B -- end-of-prompt, start of input).
Previously, clearPrompt() identified the current prompt's "area" by
searching upward from the current row until it encounters a .prompt
marker or some command output. In the bash case, .prompt is never the
dominant ("last") marker, so clearPrompt() would aggressively clear all
immediately preceding consecutive prompts.
With this change, we'll stop searching upwards when we encounter some
command output, a .prompt marker, _or another .input marker_. That last
case prevents clearPrompt() from unintentionally clearing earlier prompt
lines.
There may be improvements we can make to the way that our bash shell
integration emits semantic prompt markers, but I think this logic is
generally sound for all cases, and it specifically improves the current
bash prompt-clearing experience.
