To reproduce the issue:
"
If you already have the multi-key enabled on your system, then add this line
to your ~/.XCompose file:
[...]
<question> <T> <E> <S> <T> <question> :
"1234567890123456789012345678901234567890123456789012345678901234567890"
"
Reported by and an initial patch by Andy Gozas <andy@gozas.me>, 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.
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.
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!
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.
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
st could easily tear/flicker with animation or other unattended
output. This commit eliminates most of the tear/flicker.
Before this commit, the display timing had two "modes":
- Interactively, st was waiting fixed `1000/xfps` ms after forwarding
the kb/mouse event to the application and before drawing.
- Unattended, and specifically with animations, the draw frequency was
throttled to `actionfps`. Animation at a higher rate would throttle
and likely tear, and at lower rates it was tearing big frames
(specifically, when one `read` didn't get a full "frame").
The interactive behavior was decent, but it was impossible to get good
unattended-draw behavior even with carefully chosen configuration.
This commit changes the behavior such that it draws on idle instead of
using fixed latency/frequency. This means that it tries to draw only
when it's very likely that the application has completed its output
(or after some duration without idle), so it mostly succeeds to avoid
tear, flicker, and partial drawing.
The config values minlatency/maxlatency replace xfps/actionfps and
define the range which the algorithm is allowed to wait from the
initial draw-trigger until the actual draw. The range enables the
flexibility to choose when to draw - when least likely to flicker.
It also unifies the interactive and unattended behavior and config
values, which makes the code simpler as well - without sacrificing
latency during interactive use, because typically interactively idle
arrives very quickly, so the wait is typically minlatency.
While it only slighly improves interactive behavior, for animations
and other unattended-drawing it improves greatly, as it effectively
adapts to any [animation] output rate without tearing, throttling,
redundant drawing, or unnecessary delays (sounds impossible, but it
works).
This line didn't work at mshortcuts at config.h:
/* mask button function arg release */
{ ShiftMask, Button2, selpaste, {.i = 0}, 1 },
and now it does work.
The issue was that XButtonEvent.state is "the logical state ... just prior
to the event", which means that on release the state has the Button2Mask
bit set because button2 was down just before it was released.
The issue didn't manifest with the default shift + middle-click on release
(to override mouse mode) because its specified modifier is XK_ANY_MOD, at
which case match(...) ignores any specific bits and simply returns true.
The issue also doesn't manifest on press, because prior to the event
Button<N> was not down and its mask bit is not set.
Fix by filtering out the mask of the button which we're currently matching.
We could have said "well, that's how button events behave, you should
use ShiftMask|Button2Mask for release", but this both not obvious to
figure out, and specifically here always filtering does not prevent
configuring any useful modifiers combination. So it's a win-win.
XCreateIC ICValues default XNFocusWindow to XNClientWindow if not
specified, it can be omitted since it is the same.
From the documentation
https://www.x.org/releases/current/doc/libX11/libX11/libX11.html
> Focus Window
>
> The XNFocusWindow argument specifies the focus window. The primary
> purpose of the XNFocusWindow is to identify the window that will receive
> the key event when input is composed.
>
> When this XIC value is left unspecified, the input method will use the
> client window as the default focus window.
Do not try to set specific IM method, let the user specify it with
XMODIFIERS.
If the requested method is not available or opening fails, fallback to
the default input handler and register a handler on the new IM server
availability signal.
Do the same when the input server is closed and (re)started.
Current buffer is too short to input medium to long sentences from IME.
Input with longer text will show the wrong input, taking 64 instead of
32 bytes should be enough for most of the cases. Broken cases before,
Chinese (taken from song 也可以)
可不可以轻轻的松开自己
Japanese (taken from bootleggers rom quote)
あなたは家のように感じる
For WM_CLASS this is mentioned in the ICCCM docs
https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.5
(third sentence).
When changing the WM_CLASS from the command line, this is necessary for
window managers to pick it up before applying class-based rules.
The recent mouse shurtcuts commits allow customization, but ignore
forcemousemod mask (default: shift) as a modifier, for no good reason
other than following the behavior of the KB shortcuts.
Allow using forcemousemod too, which now can be used to invoke
different shortcuts, though the automatic effect of forcemousemod will
be lost for buttons which use mask with forcemousemod.
E.g. the default is:
static uint forcemousemod = ShiftMask;
...
{ XK_ANY_MOD, Button4, ttysend, {.s = "\031"} },
...
where ttysend will be invoked for button4 with any mod when not in mouse
mode, and with shift when in mouse mode.
Now it's possible to do this:
{ ShiftMask, Button4, ttysend, {.s = "foo"} },
{ XK_ANY_MOD, Button4, ttysend, {.s = "\031"} },
Which will invoke ttysend("foo") while shift is held and ttysend("\031")
otherwise. Shift still overrides mouse mode, but will now send "foo".
Previously with this setup the second binding was always invoked
because the forceousemod mask was always removed from the event.
Buttons which don't use forcemousemod behave the same as before.
This is useful e.g. for the scrollback mouse patch, which wants to
configure shift+wheel for scrollback, while keeping the normal behavior
without shift.
Because selpaste is activated on release, a release flag was added to
mouse shortcuts which controls whether activation is on press/release,
and selpaste binding to button2 was moved to config.h .
button1 remains the only hardcoded mouse button - for selection + copy.
Allow forceselmod to override all mouse shortcuts rather than only
selection, and rename it to forcemousemod as it's now more appropriate.
This will affect mouse shortcuts which use mask other than XK_ANY_MOD.
This does not affect the default behavior because the default mouse
shortcuts (wheel) use XK_ANY_MOD, where forceselmod already activated
the override also before this change.
Previously, if a mouse shortcut was configured with a specific mod and
forceselmod was held, then the shortcut did not execute unless the
configured mod included forceselmod.
Current font caching algorithm contains a use after free error. A font
removed from `frc` might be still listed in `wx.specbuf`. It will lead
to a crash inside `XftDrawGlyphFontSpec()`.
Steps to reproduce:
$ st -f 'Misc Tamsyn:scalable=false'
$ curl https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
Of course, result depends on fonts installed on a system and fontconfig.
In my case, I'm getting consistent segfaults with different fonts.
I replaced a fixed array with a simple unbounded buffer with a constant
growth rate. Cache starts with a capacity of 0, gets increments by 16,
and never shrinks. On my machine after `cat UTF-8-demo.txt` buffer
reaches a capacity of 192. During casual use capacity stays at 0.
Features:
- Allow input methods swap with hotkey (E.g. left ctrl + left shift).
- Over-the-spot pre-editing style, pre-edit data placed over insertion point.
- Restart IME without segmentation fault.
TODO:
- Automatically pickup IME if st started before IME
