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.
ref. https://git.suckless.org/st/commit/ef0551932fb162f907b40185d2f48c3b497708ee.html
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!
Ref. https://git.suckless.org/st/commit/2f6e597ed871cff91c627850d03152cae5f45779.html
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.
This reverts commit e8392b282c2eaa28725241a9612804fb55113da4.
There is currently a bug in older ncurses versions (like on OpenBSD) where a
fix for a bug with REP is not backported yet. Most likely in tty/tty_update.c:
Noticed while using lynx (which uses ncurses/curses).
To reproduce using lynx: echo "Z0000000" | lynx -stdin
or using the program:
int
main(void)
{
WINDOW *win;
win = initscr();
printw("Z0000000");
refresh();
sleep(5);
return 0;
}
This prints "ZZZZZZZ" (incorrectly).
The sequence \e[Nb prints the last printed char N (more) times if it's
printable, and it's ignored after newline or other control chars.
This is Ecma-048/ANSI-X3.6 sequence and not DEC VT. It's supported by
xterm, and ncurses uses it when possible, e.g. when TERM is xterm* (and
with this commit also st*).
xterm supports only codepoints<=255, possibly due to internal limits.
We support any value/codepoint which was placed in a cell.
To test:
- tput rep 65 4 -> prints 'AAAA'
- printf "\342\225\246\033[4b" -> prints U+2566 1+4 times.
St uses a very good hack where mouse wheel genereates ^Y and ^E,
that are the same keys that less and vi uses for backward and
fordward scrolling. Scroll, as many terminal emulators, use
shift+Prev/Next for scrolling, but it is also using ^E and ^Y
for scroling, characters that are reserved in the POSIX shell
in emacs mode for end of line and yanking, making scroll unsable
in st.
This patch adds a new hack, making shift+wheel returning the
same sequences than shift+Prev/Next, meaning that scroll or
any other similar program will not be able to differentiate
between them.
