On Fri, 29 Apr 2022 10:31:14 +0200 Hiltjo Posthuma <hil...@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