On Fri, 29 Apr 2022 10:31:14 +0200
Hiltjo Posthuma <hiltjo_AT_codemadness.org> wrote:
Dear Hiltjo,
> Reading through the long wall of text (*sigh*). I'll try to respond
> to the relevant parts of the actual topic.
>
> There won't be grapheme support into dmenu or dwm (until decided
> otherwise for whatever reason), it is too complex.
libgrapheme (currently) doesn't even offer a solution for what is
discussed. It can only count grapheme, not give any information on how
large a "rendered" grapheme is. The Unicode consortium points at font
rendering/shaping engines, so as it's done right now in dmenu is
correct and I didn't advertise to use libgrapheme.
> There won't be a progress indicator, dmenu should just be fast in the
> common cases and start up instantly(tm). Instantly is of course a
> very scientific measurement for "it feels good/fast man".
Yes, a progress indicator would be nonsense in the general case of
course. In the general case, though, dmenu won't block when reading
from stdin and I proposed a "busy" indication only in the case a read
from stdin blocks. What I proposed was that dmenu does it all
asynchronously and actually creates a window and allows keyboard input
even when stdin hasn't even been fully consumed yet.
This would ensure minimal latency on startup and until you can enter a
query, but would also usually not show a progress indicator, as it
would usually not block when reading from stdin (which it would do at
least once before running the string matching algorithm).
Technically we'd just shift latency from startup to after the window is
opened, but the user can already take the few miliseconds to enter a
query until it is run on the, now consumed, data.
For the rare case the read from stdin blocks, a busy indication could
be shown, but as I said, it'll not be done in the usual case.
> Performance improvements in drawing and searching for dmenu are fine
> aslong as they are simple and fix a real practical issue. (Relative)
> simplicity is still one of the most important goals.
Yeah, I totally agree. I must admit that I'm not too accustomed with
dmenu's code base, but what I propose would more or less boil down to
some reordering. With good data structures the "growing" selection-data
would be realtively simple to implement.
> It is also good to keep in mind by now quite some people use dmenu
> and other suckless tools (suckless tarballs are mainstream media!),
> so being a bit conservative now in dmenu is fine in my opinion.
Totally understandable. It would be cool though to be able to just
ignore the f-flag when we manage to find a way to handle both cases of
input well.
This conservatism reminds me of Kelvin versioning[0]. :)
What's your stance on Wayland-support in dmenu? Would you accept a
patch?
With best regards
Laslo
[0]:
https://jtobin.io/kelvin-versioning
Received on Fri Apr 29 2022 - 16:57:20 CEST