From 68d1ad9b54e952e3079356aeab8ab37e44c56c2c Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Tue, 4 Oct 2022 19:40:30 +0200 Subject: [PATCH 1/5] bump version to 0.9 --- config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mk b/config.mk index ddf278a..1e306f8 100644 --- a/config.mk +++ b/config.mk @@ -1,5 +1,5 @@ # st version -VERSION = 0.8.5 +VERSION = 0.9 # Customize below to fit your system From e5e959835b195c023d1f685ef4dbbcfc3b5120b2 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Tue, 25 Oct 2022 17:11:11 +0200 Subject: [PATCH 2/5] fix buffer overflow when handling long composed input To reproduce the issue: " If you already have the multi-key enabled on your system, then add this line to your ~/.XCompose file: [...] : "1234567890123456789012345678901234567890123456789012345678901234567890" " Reported by and an initial patch by Andy Gozas , thanks! Adapted the patch, for now st (like dmenu) handles a fixed amount of composed characters, or otherwise ignores it. This is done for simplicity sake. --- x.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/x.c b/x.c index 2a3bd38..aa09997 100644 --- a/x.c +++ b/x.c @@ -1833,7 +1833,7 @@ void kpress(XEvent *ev) { XKeyEvent *e = &ev->xkey; - KeySym ksym; + KeySym ksym = NoSymbol; char buf[64], *customkey; int len; Rune c; @@ -1843,10 +1843,13 @@ kpress(XEvent *ev) if (IS_SET(MODE_KBDLOCK)) return; - if (xw.ime.xic) + if (xw.ime.xic) { len = XmbLookupString(xw.ime.xic, e, buf, sizeof buf, &ksym, &status); - else + if (status == XBufferOverflow) + return; + } else { len = XLookupString(e, buf, sizeof buf, &ksym, NULL); + } /* 1. shortcuts */ for (bp = shortcuts; bp < shortcuts + LEN(shortcuts); bp++) { if (ksym == bp->keysym && match(bp->mod, e->state)) { From 7e8050cc621f27002eaf1be8114dee2497beff91 Mon Sep 17 00:00:00 2001 From: Hiltjo Posthuma Date: Sun, 5 Feb 2023 13:29:35 +0100 Subject: [PATCH 3/5] 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 4/5] 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 5/5] 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