Hi On Sat, Mar 19, 2022 at 12:59 PM Stein Gunnar Bakkeby <bakk...@gmail.com> wrote: > > Hi NRK, > > I was tinkering with this for a few hours earlier this week and there are > several issues with this area of code and not specifically related to this > modification of the patch. > > The handling of adding the ellipsis (...) when the text is too long is rather > hacky and can cause several issues. > > The general idea is that: > - we work out how many consecutive characters we can print for the same > font > - then we check if the length of the string exceeds the remaining drawable > space > - if it is too long then we check the length of the string for every > character until we find that it no longer fits > - then we replace the last three bytes with periods (.) > > These are the problematic areas I have found: > > 1. In the original code the text is allowed to bleed into the right padding > as long as it fits (I presume this is intentional). If you add one more > character then the text is too long and it will crop of four characters to > add the ellipsis. This has to do with that the for loop reduces len once more > than necessary. > > 2. The adding of the ellipsis naively assumes that the last characters in the > string are single-byte UTF-8 characters. As such when it replaces the last > bytes of the string then you can end up with split multi-byte UTF-8 > characters which can have various effects.
I *think* I somewhat improved this issue in `vis-menu` (which is based on `dmenu`, IIRC): https://github.com/Shugyousha/vis/commit/d59b98d934815e54320ad000eebfdaaf8fee344d Note that this is not well tested and still has issues though. Cheers, Silvan
