The existing logic leads to leaks in several scenarios:
1. Neither `wl_pointer_destroy` nor `wl_touch_destroy` are ever called,
so pointer and touch objects are never released.
2. The logic for `wl_keyboard_destroy` is not solid as seats can lose
the `WL_SEAT_CAPABILITY_POINTER` capability without losing the
`WL_SEAT_CAPABILITY_KEYBOARD`. Thus it's possible for the calls to
`wl_seat_get_keyboard` and `wl_keyboard_destroy` to be unbalanced.
3. Those resources were not released in the renderer destructor.
This reworks the seat resource release logic in a systematic way to
ensure that seat resources are always released.
Make sure that we release the memory used by each `wl_list` node that
was previously allocated with `calloc`.
I'm not sure if freeing the memory of the nodes without removing it
from the `wl_list` first could cause any problem so prefer removing it
from the list before releasing the memory.
When running bemenu like:
env BEMENU_OPTS="--list 3" bemenu
Valgrind will report an out-of-bounds read:
Invalid read of size 1
at 0x10BC91: do_getopt.part.0 (common.c:366)
by 0x10C635: do_getopt (common.c:340)
by 0x10C635: parse_args (common.c:556)
by 0x10B535: main (bemenu.c:55)
Address 0x4ac13e2 is 0 bytes after a block of size 2 alloc'd
at 0x4849BF3: calloc (vg_replace_malloc.c:1675)
by 0x10C533: cstrcopy (common.c:120)
by 0x10C533: tokenize_quoted_to_argv (common.c:146)
by 0x10C60C: parse_args (common.c:555)
by 0x10B535: main (bemenu.c:55)
The problem is that the parsing code for `--list` will blindly compare
a character past the number of lines to parse for e.g. `--list '3 up'`
but the end of the string may come right after the number of lines.
In my system Valgrind does not find the error when running bemenu like
`bemenu --list 3` even though the logic is equally questionable.
Fix it by checking that there is more after the number of lines.
On X11, not all programs offer this target, e.g. some terminals like
XTerm. The target "UTF8_STRING" has worked fine for many years and it is
what dmenu uses.
On Wayland, wl-paste supports the special type "text", which attempts to
autodetect a suitable type (in case there is no exact match for
"text/plain").
First, this behavior now matches that of dmenu. People switching over
from dmenu might be used to this.
I would argue, though, that it is more comfortable in general anyway:
The "primary" selection is often easier to access, you can just select
some text and be done with it, no need to reach for C-c (or even C-S-c
in terminals). Some programs like XTerm can't even put text into the
"clipboard" selection without special configuration. It thus makes sense
to make this selection available with a hotkey that's easier to reach (I
find C-y to be much more comfortable than C-Y). Only in rare
circumstances do I need to access the "clipboard" selection.
In practice, this change is *probably* not a (very) breaking change for
users, because you very often have to select some text first using a
mouse (thus putting it into the "primary" selection) before you can put
it into the "clipboard" selection using something like C-c. This means
that pasting from "primary" almost acts as a "magic" hotkey that does
"the right thing".
Previously, C-y pasted the "primary" selection on X11 and the
"clipboard" selection on Wayland. That's inconsistent and confusing,
especially when you're switching back and forth between the two.
This commit does two things:
1. It makes C-y always paste the "clipboard" selection.
2. It adds a key bind C-Y to paste the "primary" selection.
I suspect that most bemenu users are on Wayland, so this commit tries to
not break things for them. It does, however, change the behavior on X11.
This reverts commit 943d74600e.
This fix the BEMENU_SCALE that was left unused when fractionnal scale
support was detected.
This is rebased over origin/master.
