On Mon, Mar 21, 2022 at 07:00:32PM +0600, NRK wrote: > The only "issue" is that it doesn't render the ellipsis in case font > changes, but current upstream dmenu doesn't seem to do it either.
OK, I think I have a solution to this. The problem here, as far as I understand, is this: Let's say we have a maxwidth of 100, and printing the ellipsis takes 20. In this case as long as our string is below 80, we're fine; and if it's above 100 then we should print up to 80 and then print the ellipsis. The problem case is when we're between 80-100, and we need to change font. The current code always renders whatever is available when we change font, so if the text turns out to be bigger than 100 we've already rendered some of the text into the problem area where the ellipsis should've been. The solution I came up with is to simply not render anything if we're at the problem case, and instead put the problem cases into a queue and keep going forwards until either: 1) The text overflows, in which case we discard the queue and just print the ellipsis instead. 2) Encounter the end of text, which means the text barely fit into our maxwidth (this would happen with the prompt); in which case we just render the queue and don't print any ellipsis. I already have a patch that *roughly* does what I described above and with it applied I don't see any truncation problems anymore. However the patch is quite messy atm, and in order to do things cleanly and avoid special casing, I think a good portion of drw_text() will need to be overhauled to use a queue like this: struct { const char *str; int len; Fnt *fnt; } q[32] = {0}; I'm not sure if such overhaul is going to be welcome or not, but if all of this sounds acceptable then I can proceed with cleaning things up and supplying the patch. - NRK