This adds support for OSC 110, 111, and 112 escape sequences to reset the foreground, background, and cursor colors in the terminal. The changes include handling these sequences in the `strhandle` function of `st.c`, allowing applications to reset colors to their default values. The OSC sequences originated from Xterm control sequences and are now widely used in terminal applications and supported by many terminal emulators. For applications, this allows them to reset colors to default values without needing to know the colors beforehand. Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com>

This is used in the wild by systemd systemctl for example and st misinterpreted it as "blink", because it didn't know "58", then saw "5" as "blink", and then didn't know "245". This should print "foo" as normal text: printf '\e[58:5:245mfoo\n' printf '\e[58:2:50:100:200mfoo\n'

The kitty keyboard protocol docs recommend CSI ? u to query support for that protocol, see https://sw.kovidgoyal.net/kitty/keyboard-protocol/ For better or worse, fish shell uses this query to work around bugs in other terminals triggered by requesting that protocol via CSI = 5 u. Unfortunately, st interprets CSI ? u as DECRC (restore cursor position). reproduce with 'printf "\x1b[?u"; cat'. fish could work around this by switching to the alternate screen before running this query; but that might cause tearing on terminals that don't support Synchronized Output. I'm not sure. In the meantime, let's correct our parser. This adds a redundant else-after-return, for consistency with the surrounding code.

With sequence \e[1J, if cursor is on second line, clear the first line.

When embedded, st fails with BadMatch error if the embedder's window has non-default colormap/depth/visual. This commit fixes that by creating st's window inside root and then reparent it into embedder. The reference window for dc.gc is also changed to match root's visuals. A similar commit had been made for dmenu[1]. See this issue[2] on github for context. [1]: https://git.suckless.org/dmenu/commit/0fe460dbd469a1d5b6a7140d0e1801935e4a923b.html [2]: https://github.com/phillbush/xfiles/issues/47

Patch by Mikhail Kot <to@myrrc.dev> With some modifications to behave more like xterm (see note below). Example: printf '\033[48;2;255:0:0mtest\n' https://invisible-island.net/xterm/ctlseqs/ctlseqs.html Some notes: "CSI Pm m Character Attributes (SGR). [...] o xterm allows either colons (standard) or semicolons (legacy) to separate the subparameters (but after the first colon, colons must be used).

With this patch, st will reset its window title when an empty string is given as the terminal title. For example: printf "\033]0;\007" Some applications, like termdown, expect this functionality. xterm implements it, but it seems that most other terminal emulators don't. In any case, I don't see why there should ever be a case where the st window doesn't have a title property.

This reverts commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5. This patch needs some more work. It caused regressions with programs that use GNU readline, etc. Original test-case example from Tim Culverhouse <tim@timculverhouse.com>: printf " 😀" && sleep 2 && printf "\e[D" && sleep 2 && printf "\e[D" && sleep 2 After the patch it caused regressions, example test-case: printf "A字\bB\n"

Previously, printf 'L\033[2147483647b' would call tputc('L') 2^31 times, making st unresponsive. This commit allows repeating the last character at most 65535 times in order to prevent freezing and DoS attacks.

st would always move back 1 column, even with wide glyhps (using more than a single column). The glyph rune is set on its first column, and the other ones are to 0, so loop until we detect the start of the previous glyph.

The handler for 'S' final character does not check for a private marker. This can cause a conflict with a sequence called 'XTSMGRAPHICS' which also has an 'S' final character, but uses the private marker '?'. Without checking for a private marker, st will perform a scroll up operation when XTSMGRAPHICS is seen, which can cause unexpected display artifacts.

Helps Vim (and hopefully others) to discover that this feature exists without further user configuration.

It is unclear if it's "required" to do this on RIS, but it's useful when calling reset(1) after interactive programs have crashed and garbled up the screen. FWIW, other terminals do it as well (tested with XTerm, VTE, Kitty, Alacritty, Linux VT).

Consider the following example: printf '\e[?7l';\ for i in $(seq $(($(tput cols) - 1))); do printf a; done;\ printf '🙈\n';\ printf '\e[?7h' Even though MODE_WRAP has been disabled, the emoji appeared on the next line. This patch keeps wide glyphs on the same line and moves them to the right-most possible position.