Starting a tool on OpenBSD from urxvt results in:
$ ncspot
ncspot:/usr/local/lib/libswmhack.so.1.0: undefined symbol 'XKeysymToKeycode'
Linking libswmhack against libX11 fixes this issue.
line 1785 - Wrong type
line 2486 - Division by zero
line 2575 - Uninitialized argument value
line 2583 - Uninitialized argument value
line 2595 - Uninitialized argument value
line 2597 - Uninitialized argument value
line 3468 - Wrong type
line 3730 - Dereference of null pointer
line 6065 - Result of operation is garbage or undefined
line 9374 - Wrong type
line 12446 - Possible null pointer dereference
New conf search order:
1) $XDG_CONFIG_HOME/spectrwm/spectrwm.conf
2) ~/.config/spectrwm/spectrwm.conf
(if $XDG_CONFIG_HOME is either not set or empty)
3) ~/.spectrwm.conf
4) $XDG_CONFIG_DIRS/spectrwm/spectrwm.conf
(each colon-separated directory in $XDG_CONFIG_DIRS)
5) /etc/xdg/spectrwm/spectrwm.conf
(if $XDG_CONFIG_DIRS is either not set or empty)
6) /etc/spectrwm.conf
In get_binding_keycode() a uint8_t loop variable was incremented in a
for loop. The variable would overflow right before the loop's
condition was met. Therefore the loop would never terminate.
To avoid the infinite loop the condition has to be checked before the
increment operation and not afterwards.
xcb_key_symbols_get_keycode() returns a list of keycodes that is ordered
by keycode value instead of keyboard layout order. If a keysym resolves
to multiple keycodes, the first keycode in the returned array may be from
the wrong layout.
For example, if the current keymap has two layouts: 'us, us(dvorak)', 'p'
will resolve to keycode 27 of the secondary 'dvorak' layout instead of
keycode 33 of the primary 'us' layout.
Instead of using xcb_key_symbols_get_keycode() to resolve keysyms to
keycodes, search each keysym column in the key map until there is a hit.
Setting `disable_border = always` removes border from lone tiled
windows, regardless of the bar being enabled/disabled. This is an
addition to an existing feature, and does not change existing behaviour.
We're already installing most supporting data along with the
application itself, but we have been skipping additional
documentation (such as the license and release notes) and most
importantly the default configuration file.
For each release, the date it taken from the corresponding
git tag; the one exception is 2.4.0, where the tag was created
months after the commit it points to.
Information about releases is taken from [1] and minimally
edited to work in the new context, along with being fixed when
necessary.
While every single release from 1.0.0 onwards is now accounted
for, several of them lack detailed information: tracking
existing release notes about them or writing them from scratch
is left as an exercise to the reader.
[1] https://sourceforge.net/projects/scrotwm/files/
Reflow the most recent entry to fit into 80 columns, make sure
there are two empty lines between entries, and fix the release
date for spectrwm 3.0.0 (the tag was created on May 2, despite
the "releases" page on GitHub claiming otherwise).
Add XOpenDisplay intercept to preload atoms.
Looking up/creating atoms when handling XCreateWindow can cause
deadlocks and other unexpected behavior in some applications. Instead,
preload the atoms on XOpenDisplay.
Since 3.0.0, release notes for spectrwm are already being
compiled and ultimately published at
https://github.com/conformal/spectrwm/releases
but it would be useful if they were included in the release
tarball themselves as well.
The contents of the NEWS.md file are taken straight from the
page mentioned above, with only very minor editing.
man: /usr/man/man1/spectrwm.1.gz:231:18: WARNING: new sentence, new line
man: /usr/man/man1/spectrwm.1.gz:986:71: WARNING: new sentence, new line
new sentence, new line
(mdoc) A new sentence starts in the middle of a text line. Start it on a
new input line to help formatters produce correct spacing
https://man.openbsd.org/mandoc.1
On the musl libc, autorun, layout and workspace name settings were
always rejected as invalid. As it turns out, parsing those was relying
on sscanf incorrectly matching %Nc as long as there is at least one
character. This is fixed by matching only the initial part of the string
via sscanf and skipping ahead by the amount of bytes consumed. This also
avoids unnecessary zeroing, copying and possible implicit truncation.
Relevant glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=12701
