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
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
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
this patch makes some non-trivial changes, which significantly improves
the performance of drawing large strings as well as fixes any issues
regarding the printing of the ellipsis when string gets truncated.
* performance:
before there were two O(n) loops, one which finds how long we can go
without changing font, and the second loop would (incorrectly) truncate
the string if it's too big.
this patch merges the overflow calculation into the first loop and exits
out when overflow is detected. when dumping lots of emojies into dmenu,
i see some noticeable startup time improvement:
before -> after
460ms -> 360ms
input latency when scrolling up/down is also noticeably better and can
be tested with the following:
for _ in $(seq 20); do
cat /dev/urandom | base64 | tr -d '\n' | head -c 1000000
echo
done | ./dmenu -l 10
* correctness:
the previous version would incorrectly assumed single byte chars and
would overwrite them with '.' , this caused a whole bunch of obvious
problems, including the ellipsis not getting rendered if then font
changed.
in addition to exiting out when we detect overflow, this patch also
keeps track of the last x-position where the ellipsis would fit. if we
detect overflow, we simply make a recursing call to drw_text() at the
ellipsis_x position and overwrite what was there.
so now the ellipsis will always be printed properly, regardless of
weather the font changes or if the string is single byte char or not.
the idea of rendering the ellipsis on top incase of overflow was
from Bakkeby <bakkeby@gmail.com>, thanks! however the original patch had
some issues incorrectly truncating the prompt (-p flag) and cutting off
emojies. those have been fixed in here.
Ref. https://git.suckless.org/dmenu/commit/41fdabbf7c517f8d524b70cbd78238cc319ccef3.html
