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.
on debian, the bottom bar renders as squares instead of the proper
font. this fixes this, but for some reason renders a serif font
instead of the proper Fantasque Sans Mono. for now, i'm to tired to
troubleshoot, so here's a patch to get this working for now.
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