~smlavine/dmenu

Merge branch 'suckless' into smlss
e73651f1 — Hiltjo Posthuma a month ago
fix UB with the function iscntrl()

From commit 6818e07291f3b2913e687c8ec3d3fe4711724050 by NRK, thanks
31fa07b9 — Hiltjo Posthuma a month ago
Revert "avoid redraw when there's no change"

This reverts commit 6818e07291f3b2913e687c8ec3d3fe4711724050.

This broke keys such as ^W to delete-backward-word
avoid redraw when there's no change

while i was timing the performance issue, i noticed that there was lots
of random redrawing going on.

turns out there were coming from here; if someone presses CTRL/ALT etc
without pressing anything else, nothing will be inserted, so nothing
will change. but the code will `break`, go down and do a needless redraw.

this patch changes it to simply return if the keypress iscntrl()

also avoid potential UB by casting *buf into an unsigned char.
free all allocated items, use %zu for size_t

`items` itself is not checked for NULL as calling free on NULL is defined to be
a no-op.
drw_text: improve performance when there's no match

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
inputw: improve correctness and startup performance

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.
significantly improve performance on large strings

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.
introduce drw_fontset_getwidth_clamp()

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().
drw_text: improve both performance and correctness

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.
3a505ceb — Hiltjo Posthuma 2 months ago
remove false-positive warning for int comparison as bool

Reported by Prathu Baronia <prathu.baronia@praton.me>, patch slightly changed.

Thanks!
Merge branch 'suckless' into smlss
308fe78b — Hiltjo Posthuma 3 months ago suckless
bump version to 5.1
c4b656e0 — Hiltjo Posthuma 3 months ago
code-style: rm newline (oops)
3e39c526 — Hiltjo Posthuma 3 months ago
revert using strcasestr and use a more optimized portable version

... compared to the old cistrstr().

Thanks for the feedback!
a9a38368 — Hiltjo Posthuma 3 months ago
follow-up fix: add -D_GNU_SOURCE for strcasestr for some systems
eb96af27 — Hiltjo Posthuma 3 months ago
improve performance of case-insensitive matching
Re-introduce conditional min_width of 500
Revert "Revert "Apply dmenu-numbers-4.9.diff""

This reverts commit c00b82d8ba0586c0b60bd84cd6eafc3df8bb704d.
Change how centered menu width is calculated

min_width is changed from being an arbitrary compile-time value to being
defined as the prompt width.

The prompt width is no longer added to the width of the longest line to
determine the menu width. This had resulted in lines being a lot longer
than they needed to be in some cases. A downside of this is that the
input window is now sometimes smaller than can be read.
Next