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.
There is a compatibility issue between the dwm swallow patch and the
newterm patch for st.
The swallow patch identifies the terminal client to substitute by
traversing the process tree checking if the new window is a descendant
of a terminal client.
The newterm patch for st spawns a new terminal that is a descendant of
the parent st process.
This can lead to situations where the swallow patch ends up replacing
the wrong terminal window.
Changed the forking mechanism to do a double fork and letting the
first one die. This is a technique commonly used by daemons to spawn
new orphan processes.
If the mouse cursor is changed to a bar or an underline then st will use that
when the terminal is first opened. When an application that changes the cursor
via escape sequences is executed, e.g. vim which uses a block cursor by default,
then that cursor will remain after exiting the program.
This change sets the cursor back to default when exiting alt mode.
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
https://git.suckless.org/st/commit/9e68fdbcdb06dfa3d23fe3a7a7f7b59e40e1ea2f.html
bakkeby
Muhamad Althaf
Loic Coyle