From 7e8050cc621f27002eaf1be8114dee2497beff91 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Sun, 5 Feb 2023 13:29:35 +0100 Subject: [PATCH 1/4] Fixed OSC color reset without parameter->resets all colors Adapted from (garbled) patch by wim Additional notes: it should reset all the colors using xloadcols(). To reproduce: set a different (theme) color using some escape code, then reset it: printf '\x1b]104\x07' --- st.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/st.c b/st.c index 62def59..34c27ad 100644 --- a/st.c +++ b/st.c @@ -1932,8 +1932,10 @@ strhandle(void) if (p && !strcmp(p, "?")) { osc_color_response(j, 0, 1); } else if (xsetcolorname(j, p)) { - if (par == 104 && narg <= 1) + if (par == 104 && narg <= 1) { + xloadcols(); return; /* color reset without parameter */ + } fprintf(stderr, "erresc: invalid color j=%d, p=%s\n", j, p ? p : "(null)"); } else { From f17abd25b376c292f783062ecf821453eaa9cc4c Mon Sep 17 00:00:00 2001 From: Adam Price Date: Tue, 7 Feb 2023 19:54:29 +0100 Subject: [PATCH 2/4] Add support for DSR response "OK" escape sequence "VT100 defines an escape sequence [1] called Device Status Report (DSR). When the DSR sequence received is `csi 5n`, an "OK" response `csi 0n` is returned. This patch adds that "OK" response. I encountered this missing sequence when I noticed that fzf [2] would clobber my prompt whenever completing a find. To test that ST doesn't currently respond to `csi 5n`, use fzf's shell extension in ST's repo to complete the path for a file. my-fancy-prompt $ vim ** my-fancy prompt $ vim st.c Thank you for considering my first patch submission. [1] https://www.xfree86.org/current/ctlseqs.html#VT100%20Mode [2] https://github.com/junegunn/fzf " Patch slightly adapted with input from the mailinglist, --- st.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/st.c b/st.c index 34c27ad..49357cc 100644 --- a/st.c +++ b/st.c @@ -1769,11 +1769,18 @@ csihandle(void) case 'm': /* SGR -- Terminal attribute (color) */ tsetattr(csiescseq.arg, csiescseq.narg); break; - case 'n': /* DSR – Device Status Report (cursor position) */ - if (csiescseq.arg[0] == 6) { + case 'n': /* DSR -- Device Status Report */ + switch (csiescseq.arg[0]) { + case 5: /* Status Report "OK" `0n` */ + ttywrite("\033[0n", sizeof("\033[0n") - 1, 0); + break; + case 6: /* Report Cursor Position (CPR) ";R" */ len = snprintf(buf, sizeof(buf), "\033[%i;%iR", - term.c.y+1, term.c.x+1); + term.c.y+1, term.c.x+1); ttywrite(buf, len, 0); + break; + default: + goto unknown; } break; case 'r': /* DECSTBM -- Set Scrolling Region */ From 211964d56ee00a7d46e251cbc150afb79138ae37 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Tue, 7 Feb 2023 20:00:59 +0100 Subject: [PATCH 3/4] ignore C1 control characters in UTF-8 mode Ignore processing and printing C1 control characters in UTF-8 mode. These are in the range: 0x80 - 0x9f. By default in st the mode is set to UTF-8. This matches more the behaviour of xterm with the options -u8 or +u8 also. Also see the xterm resource "allowC1Printable". Let me know if this breaks something, in most cases I don't think so. As usual a very good reference is: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html --- st.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/st.c b/st.c index 49357cc..134e724 100644 --- a/st.c +++ b/st.c @@ -2422,6 +2422,9 @@ check_control_code: * they must not cause conflicts with sequences. */ if (control) { + /* in UTF-8 mode ignore handling C1 control characters */ + if (IS_SET(MODE_UTF8) && ISCONTROLC1(u)) + return; tcontrolcode(u); /* * control codes are not shown ever From 3a6d6d740110e6ee1b092d05ad746244eedabe4b Mon Sep 17 00:00:00 2001 From: Shi Tian Date: Sun, 25 Jun 2023 05:38:33 +0000 Subject: [PATCH 4/4] Fix for wide character being incorrectly cleared on MODE_INSERT MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Under insert mode, when inserting a normal character in front of a wide character, the affected region is shifted to the right by one cell. However, the empty cell is reset as if being a part of a wide character, causing the following cell being mishandled as a dummy cell. To reproduce the bug: printf '\033[4h' # set MODE_INSERT printf 妳好 printf '\033[4D' printf 'x' printf '\033[4l\n' --- st.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/st.c b/st.c index 134e724..623376e 100644 --- a/st.c +++ b/st.c @@ -2471,8 +2471,10 @@ check_control_code: gp = &term.line[term.c.y][term.c.x]; } - if (IS_SET(MODE_INSERT) && term.c.x+width < term.col) + if (IS_SET(MODE_INSERT) && term.c.x+width < term.col) { memmove(gp+width, gp, (term.col - term.c.x - width) * sizeof(Glyph)); + gp->mode &= ~ATTR_WIDE; + } if (term.c.x+width > term.col) { tnewline(1);