Because drw_scm_create() allocates it.

XUngrabKey(), which is currently used in cleanup(), is not the right counterpart to XGrabKeyboard(), which is used in grabkeyboard(), called from main(). XUngrabKeyboard() is the function to use, as grabbing the whole keyboard is different to grabbing individual keys. With the current code the keyboard gets ungrabbed, as far as I can tell, only by the final XCloseDisplay() in cleanup(), as the XUngrabKey() there effectively does nothing.

Patch by Raymond Cole <rc@wolog.xyz>, thanks.

Original patch by Raymond Cole with some modifications, thanks!

previously drw_text would do the width calculations as if invalid utf8 sequences were replaced with U+FFFD but would pass the invalid utf8 sequence to xft to render where xft would just cut it off at the first invalid byte. this change makes invalid utf8 render as U+FFFD and avoids sending invalid sequences to xft. the following can be used to check the behavior before and after the patch: $ printf "0\xef1234567\ntest" | dmenu Ref: https://lists.suckless.org/dev/2407/35646.html

this changes the utf8decode function to: * report when an error occurs * report how many bytes to advance on error these will be useful in the next commit to render invalid utf8 sequences. the new implementation is also shorter and more direct.

The Makefile used to suppress output (by using @), so this target made sense at the time. But the Makefile should be simple and make debugging with less abstractions or fancy printing. The Makefile was made verbose and doesn't hide the build output, so remove this target. Prompted by a question on the mailing list about the options target.

1. use `unsigned int` to store the codepoints, this avoids waste on common case where `long` is 64bits. and POSIX guarantees `int` to be at least 32bits so there's no risk of truncation. 2. since switching to `unsigned int` cuts down the memory requirement by half, double the cache size from 64 to 128. 3. instead of a linear search, use a simple hash-table for O(1) lookups.

When embedded into another window, dmenu will fail with the BadMatch error if that window have not the same colormap/depth/visual as the root window. That happens because dmenu inherits the colormap/depth/visual from its parent, but draws on a pixmap created based on the root window using a GC created for the root window (see drw.c). A BadMatch will occur when copying the content of the pixmap into dmenu's window. A solution is to create dmenu's window inside root and then reparent it if embeded. See this mail[1] on ports@openbsd.org mailing list for context. [1]: https://marc.info/?l=openbsd-ports&m=168072150814664&w=2

Improves upon commit 32db2b125190d366be472ccb7cad833248696144 The getline() implementation often uses a more greedy way of allocating memory. Using this buffer directly and forcing an allocation (by setting it to NULL) would waste a bit of extra space, depending on the implementation of course. Tested on musl libc and glibc. The current glibc version allocates a minimum of 120 bytes per line. For smaller lines musl libc seems less wasteful but still wastes a few bytes per line. On a dmenu_path listing on my system the memory usage was about 350kb (old) vs 30kb (new) on Void Linux glibc. Side-note that getline() also reads NUL bytes in lines, while strdup() would read until the NUL byte. Since dmenu reads text lines either is probably fine(tm). Also rename junk to linesiz.

Keep track of the amount of items (not a total buffer size), allocate an array of new items. For now change BUFSIZ bytes to 256 * sizeof(struct item)).

Maybe too obvious / redundant, but OK.

according to the getline(3) documentation, the calling code needs to free the buffer even if getline fails. dmenu currently doesn't do that which results in a small leak in case of failure (e.g when piped /dev/null) $ ./dmenu < /dev/null ==8201==ERROR: LeakSanitizer: detected memory leaks Direct leak of 120 byte(s) in 1 object(s) allocated from: #0 0x7f6bf5785ef7 in malloc #1 0x7f6bf538ec84 in __getdelim #2 0x405d0c in readstdin dmenu.c:557 moving `line = NULL` inside the loop body wasn't strictly necessary, but IMO it makes it more apparent that `line` is getting cleared to NULL after each successful iteration.

* Increase the length of composed strings to the same limit as st (32 to 64 bytes). * Initialize ksym to NoSymbol to be safe: currently this is not an issue though. * Add comments to clarify the return values of XmbLookupString a bit.

https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS

Reported by Santtu Lakkala <inz@inz.fi>, thanks!

we already need to know the string length since `cursor` needs to be adjusted. so just calculate the length beforehand and use `memcpy` to copy exactly as much as needed (as opposed to `strncpy` which always writes `n` bytes).

currently readstdin(): - fgets() into a local buffer, - strchr() the buffer to eleminate the newline - stdups() the buffer into items a simpler way is to just use getline(3), which will do the allocation for us; eliminating the need for stdup()-ing. additionally getline returns back the amount of bytes read, which eliminates the need for strchr()-ing to find the newline.