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.
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
