Normally, we queue all the writes we need from a single `read()` syscall
and only wake up the writer thread at the end of processing that batch
of data.
But under very heavy load or large batches of data, it is possible for the
terminal sequences to generate enough writes to the pty to fill the
writer thread queue while we're still processing the data from `read()`.
This modifies our queuer to attempt to queue, but if the queue is full
we wake up the writer thread immediately then queue again (which should
succeed in every case -- eventually).
Default colors are those set by the user in the config file, or an
actual default value if unset. The actual colors are modifiable and can
be changed using the OSC 4, 10, and 11 sequences.
Fixes a crash found through fuzzing. This crash is also exhibited in
xterm (as of v384). The issue arises when you set the cursor above the top
scroll margin, then issue a large cursor left (CSI D) with extended reverse
wrap (?1045) set. Extended reverse wrap loops back until it reaches the top
scroll then wraps around. But since the cursor is before the top scroll,
xterm just arbitrarily moves back into negative row numbers, which reads into
bad memory.
We decided to fix this by clamping to (0,0) and exiting because this
will mimic the xterm behavior for valid values of cursor left count
(prior to crashing).
Fixes#648
Two issues here:
- RIS should've been resetting the tabstops to every 8, but was
clearing all tabstops.
- `ESC ? W` should've reset tabstops to every 8, but was clearing
all tabstops.
Previously, we just ignored ansi vs dec modes (`?`-prefix) and just
responded to both requests most of the time using the number as the
unique value. This _kind of works_ because almost all DEC modes do not
overlap with ANSI modes, but some overlap (i.e. `insert`, ANSI mode 4).
This commit properly separates ANSI vs DEC modes and updates all of our
terminal sequences to handle both (where applicable -- some sequences
are explicitly DEC-only).
XTVERSION (CSI > 0 q) is used by some libraries to identify the terminal
+ version. Respond to this query with `ghostty {version_string}`. There
is no formal format for this response. A roundup of a few tested
terminals show two primary formats. This patch opts to save one byte and
use the `name SP version` semantics.
foot: foot(version)
xterm: XTerm(version)
contour: contour version
wezterm: wezterm version
Reference: https://github.com/dankamongmen/notcurses/blob/master/TERMINALS.md#notes-for-terminal-authors
Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
* Change state names to more human readable query_default_fg/bg
* Single-line state prongs
* String terminator is not an enum
* Removed `endWithStringTerminator` and added nullabe arg to `end`
* Fixed a color reporting bug, fg/bg wasn't correctly picked
These OSC commands report the default foreground and background colors.
Most terminals return the RGB components scaled up to 16-bit components, because some
legacy software are unable to read 8-bit components. The PR follows this conventions.
iTerm2 allow 8-bit reporting through a config option, and a similar option is
added here. In addition to picking between scaled and unscaled reporting, the user
can also turn off OSC 10/11 replies altogether.
Scaling is essentially c / 1 * 65535, where c is the 8-bit component, and reporting
is left-padded with zeros if necessary. This format appears to stem from the XParseColor
format.
