Follow-up on pull request #16 this change refactors and combines
the highlight and fuzzy highlight patches into one highlight
function.
Overall it does not make any sense using:
- fuzzy highlighting when exact matching is used or
- exact highlighting when fuzzy matching is used
As such it makes sense to combine the two such that:
- exact highlighting is used when exact matching is used and
- fuzzy highlighting is used when fuzzy matching is used
The FUZZYHIGHLIGHT_PATCH toggle has been removed in favour of
HIGHLIGHT_PATCH. The FUZZYMATCH_PATCH toggle controls whether
fuzzy matching is enabled. Enable both FUZZYMATCH_PATCH and
HIGHLIGHT_PATCH to enable fuzzy highlighting.
Additionally the fuzzy highlight patch only supported single-byte
characters and would break when encountering multi-byte UTF-8
characters. This was reported ref. #24.
This refactoring includes a change to work out the UTF-8 character
length for a given character rather than assuming that every
character uses one byte.
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.
ref.
https://git.suckless.org/dmenu/commit/7ab0cb5ef0e19352fc5d64ae0d57a5cf4540acbf.html
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.
ref.
https://git.suckless.org/dwm/commit/9f8855343c881bdc01b9fff5b956537ba1106b76.html
The highlight feature by default overrides other colour schemes and
may in the process partially or fully obscure that an item has already
been output (or is scheduled for output using the multiselect patch).
In this context the highlighting does not add any valuable information
given that the user has already selected the item. Overall it seems
more user-friendly to skip drawing highlights for outputted items.
fix BadMatch error when embedding on some windows
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
Ref.
https://git.suckless.org/dmenu/commit/0fe460dbd469a1d5b6a7140d0e1801935e4a923b.html
readstdin: reduce memory-usage by duplicating the line from getline()
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.
Ref.
https://git.suckless.org/dmenu/commit/dfbbf7f6e1b22ccf9e5a45d77ee10995577fb4fc.html
fix leak when getline fails
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.
Ref.
https://git.suckless.org/dmenu/commit/689d9bfcf6859e5ce85c296ff0f23b5c08b1fedc.html
dmenu: small XmbLookupString code improvements
* 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.
Ref.
https://git.suckless.org/dmenu/commit/e42c03663442f5fb2f66dd59cc5bfdc61c53192c.html
This patch is simpler than, and superior to, the TSV patch and as
such takes precedence if both are combined.
Also addressed some compatibility issues and compilation errors.
Reasoning:
- the patch is old and incompatible and conflicts with so many
other patches
- the functionality is rather limited especially considering that
it is generally possible to convert json data to work with the
TSV patch or the separator patch
- the patch is for dmenu 4.9, which means that since February 2009
nobody has bothered upgrading this patch to 5.0 or 5.1, which
again implies that not many people actually use or rely on this
patch
The json patch may be re-introduced into dmenu-flexipatch in the
future, but in that case it would be a bespoke version that is
designed around some of the other patches and takes more liberties
rather than trying to adhere to what is available at
https://tools.suckless.org/dmenu/patches/json/
Example using jq to convert json data to TSV format:
$ cat ~/.bookmarks
{
"uggah": "buggah",
"hello": "there",
"bye": "tomorrow"
}
$ cat ~/.bookmarks | jq -r '. | to_entries | .[] | "\(.key)\t\(.value)"'
uggah buggah
hello there
bye tomorrow
readstdin: use getline(3)
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.
Ref.
https://git.suckless.org/dmenu/commit/32db2b125190d366be472ccb7cad833248696144.html
drw_text: account for fallback fonts in ellipsis_width
additionally, ellipsis_width (which shouldn't change) is made static to
avoid re-calculating it on each drw_text() call.
this was the last piece of the puzzle, the case where we can't find any
font to draw the codepoint.
in such cases, we use XftFontMatch() which is INSANELY slow. but that's
not the real problem. the real problem was we were continuously trying
to match the same thing over and over again.
this patch introduces a small cache, which keeps track a couple
codepoints for which we know we won't find any matches.
with this, i can dump lots of emojies into dmenu where some of them
don't have any matching font, and still not have dmenu lag insanely or
FREEZE completely when scrolling up and down.
this also improves startup time, which will of course depend on the
system and all installed fonts; but on my system and test case i see the
following startup time drop:
before -> after
60ms -> 34ms
ref. https://git.suckless.org/dmenu/commit/22511c41d55a38a770541ae617a09383d5e6ad1c.html
a massive amount of time inside readstdin() is spent trying to get the
max input width and then put it into inputw, only for it to get clamped
down to mw/3 inside setup().
it makes more sense to calculate inputw inside setup() once we have mw
available. similar to the last patch, i see noticeable startup
performance improvement:
before -> after
160ms -> 60ms
additionally this will take fallback fonts into account compared to the
previous version, so it's not only more performant but also more correct.
ref. https://git.suckless.org/dmenu/commit/77526f756e23e362081ac807521f901f2e5cd5e6.html
Disclaimer: this may break the JSON patch
this replaces inefficient pattern of `MIN(TEXTW(..), n)` with
drw_fontset_getwidth_clamp() instead, which is far more efficient when
we only want up to a certain width.
dumping a decently sized (unicode) emoji file into dmenu, I see the
startup time drop significantly with this patch.
before -> after
360ms -> 160ms
this should also noticeably improve input latency (responsiveness) given
that calcoffsets() and drawmenu() are pretty hot functions.
ref. https://git.suckless.org/dmenu/commit/7269c5355d257dd2ad2c53f15dc9c1cf6796aea5.html
getting the width of a string is an O(n) operation, and in many cases
users only care about getting the width upto a certain number.
instead of calling drw_fontset_getwidth() and *then* clamping the
result, this patch introduces drw_fontset_getwidth_clamp() function,
similar to strnlen(), which will stop once we reach n.
the `invert` parameter was overloaded internally to preserve the API,
however library users should be calling drw_fontset_getwidth_clamp() and
not depend upon internal behavior of drw_text().
ref. https://git.suckless.org/dmenu/commit/6be057f060543bb0f3ed9423904263617cdffffe.html
