The --enable-wgetch-events codepath is experimental (according to
ncurses-6.2/INSTALL) and off by default (according to
ncurses-6.2/configure.in). With that codepath disabled, the macro
KEY_EVENT is not provided, which (before this commit) manifested as a
build-time error:
[ 245s] gcc -c -I. -I../../Src -I../../Src -I../../Src/Zle -I. -DHAVE_CONFIG_H -DMODULE -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -I/usr/include/ncursesw -fPIC -o curses..o curses.c
[ 246s] In file included from curses.c:210:
[ 246s] curses_keys.h:93:15: error: 'KEY_EVENT' undeclared here (not in a function); did you mean 'KEY_RESET'?
[ 246s] 93 | {"EVENT", KEY_EVENT},
[ 246s] | ^~~~~~~~~
[ 246s] | KEY_RESET
curses_keys.h is only used for setting the "kevent" output parameter of
'zcurses input' (and the associated $zcurses_keycodes special variable),
so there's no harm in just leaving KEY_EVENT out of it. (That codepath
deals gracefully with numeric values that don't correspond to any of the
known compile-time values, as that can happen whenever the build- and
run-time versions of ncurses don't provide the same set of KEY_* macros,
with or without relation to that configure flag.)
Reported by Martin Liska.
This avoids the send-break which is both visually unappealing and might
break some use cases where the user wishes to wrap edit-command-line in
another widget.
Actual behaviour:
% is-at-least 5.8.0.2 5.8 && echo yes || echo no
yes
% is-at-least 5.8.0.2 5.8.0.0 && echo yes || echo no
no
Expected behaviour: Both commands should have printed "no".
To reproduce, go to a hg repository with active mq guards and configure
vcs_info as follows:
zstyle '*' get-unapplied true
zstyle ':vcs_info:*set-patch-format*' hooks f
zstyle '*' patch-format '[%g : %G]'
zstyle '*' nopatch-format '[%g : %G]'
zstyle '*' formats '%m'
+vi-f () {
hook_com[guards]+=XXX
}
The regression was first released in 5.3.1-test-2, over three years ago.
The difference was mostly harmless in the common case "(see manref(foo)(42))",
which expanded to "(see man page foo(42))" under ztexi.yo, but in other
contexts the ztexi.yo expansion was was nonsensical; for example:
"the BSD manref(echo)(1) command"
"the string returned by the manref(getlogin)(3) system call"
"advisory file locking (via the manref(fcntl)(2) system call)"
"this is the exact opposite from manref(ls)(1),"
While there, copyedit some uses of manref()().
Remove calls to programs from /sbin/ with _call_program and to avoid the
system complies to the FHS.
Support modules completion for NixOS and Guix which store their kernel
modules not at /lib/modules.
