It is fixed in libXft 2.3.6: https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS

* adds missing function prototype * move xgetcolor() prototype to win.h (that's where all the other x.c func prototype seems to be declared at) * check for snprintf error/truncation * reduces code duplication for osc 10/11/12 * unify osc_color_response() and osc4_color_response() into a single function the latter two was suggested by Quentin Rameau in his patch review on the hackers list.

the array is not accessed outside of base64dec() so it makes sense to limit it's scope to the related function. the static-storage duration of the array is kept intact. this also removes unnecessary explicit zeroing from the start and end of the array. anything that wasn't explicitly zero-ed will now be implicitly zero-ed instead. the validity of the new array can be easily confirmed via running this trivial loop: for (int i = 0; i < 255; ++i) assert(base64_digits[i] == base64_digits_old[i]); lastly, as pointed out by Roberto, the array needs to have 256 elements in order to able access it as any unsigned char as an index; the previous array had 255. however, this array will only be accessed at indexes which are isprint() || '=' (see `base64dec_getc()`), so reducing the size of the array to the highest printable ascii char (127 AFAIK) + 1 might also be a valid strategy.

all the ctype.h functions' argument must be representable as an unsigned char or as EOF, otherwise the behavior is undefined.

Build on auto-sync and only mark window dirty on palette changes and let the event handler do the actual draw.

This patch replaces the previous one I sent. The following changes are made in this patch: - Fix tracking of pressed buttons. Previously, pressing two buttons and then releasing one would make st think no buttons are pressed, which in particular broke MODE_MOUSEMOTION. - Always send the lowest-numbered pressed button on motion events; when no button is pressed for a motion event in MODE_MOUSEMANY, then send a release. This matches the behaviour of xterm. (Previously, st sent the most recently pressed button in the motion report.) - Remove UB (?) access to potentially inactive struct member e->xbutton.button of XEvent union. - Fix (unlikely) possibility of overflow for large button numbers. The one discrepancy I found between st and xterm is that xterm sometimes encodes buttons with large numbers (>5) strangely. E.g., xterm reports presses of buttons 8 and 9 as releases, whereas st properly (?) encodes them as presses.

Overtyping the first half of a wide character with the second half of a wide character results in display garbage. This is because the trailing dummy is not cleaned up. i.e. ATTR_WIDE, ATTR_WDUMMY, ATTR_WDUMMY Here is a short script for demonstrating the behavior: #!/bin/sh alias printf=/usr/bin/printf printf こんにちは！; sleep 2 printf '\x1b[5D'; sleep 2 printf へ; sleep 2 printf ' '; sleep 2 echo

According to the spec the argument is optional for 104, so p can be NULL as can be tested with printf '\x1b]104\x07'. This is a regression of 8e31030.

Otherwise the message "erresc: unknown str" is printed.

from the XmbTextListToTextProperty(3) man page: "If insufficient memory is available for the new value string, the functions return XNoMemory. If the current locale is not supported, the functions return XLocaleNotSupported. In both of these error cases, the functions do not set text_prop_return." Reported by Steffen Nurpmeso <steffen@sdaoden.eu>, thanks!

In the current implementation, the slave PTY (assigned to the variable `s') is always closed after duplicating it to file descriptors of standard streams (0, 1, and 2). However, when the allocated slave PTY `s' is already one of 0, 1, or 2, this causes unexpected closing of a standard stream. The same problem occurs when the file descriptor of the master PTY (the variable `m') is one of 0, 1, or 2. In this patch, the original master PTY (m) is closed before it would be overwritten by duplicated slave PTYs. The original slave PTY (s) is closed only when it is not one of the stanrad streams.

The bits of uint signal in an XKeyEvent which concern the key group (keyboard layout) are bits 13 and 14, as documented here: https://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html#Groups_and_Shift_Levels In the older version, only bit 13 was marked as part of XK_SWITCH_MOD, this causes issues for users who have more than two keymaps. the 14th bit is not in ignoremod, key sequences are not caught by match(), if they switch to a third or fourth keyboard.

Only touch a few things, the main focus is to improve code readability.

These are typically mapped in X11 to the side-buttons (backward/forwards) on the mouse. A comparison of the button numbers in SGR mode (first field): st old: 0 1 2 64 65 66 67 68 69 70 st new (it is the same as xterm now): 0 1 2 64 65 66 67 128 129 130 A script to test and reproduce it, first argument is "h" (on) or "l" (off): #!/bin/sh printf '\x1b[?1000%s\x1b[?1006%s' "$1" "$1" for n in 1 2 3 4 5 6 7 8 9 10; do printf 'button %d\n' "$n" xdotool click "$n" printf '\n\n' done

Also added _NET_WM_ICON_NAME.