Thanks, but that doesn't explain enough. Please tell more about the
need to truncate completion candidates "inside a confined pop up box".
If that box is displayed, why doesn't Emacs truncate the text
automatically? Or maybe I don't understand how this "pop up box",
whatever it is, is displayed?
Each completion in a list of completion candidates is a triple of (candidate string, prefix, annotation), all in varying widths. Aligning these 3 columns requires calculating paddings. Since there are paddings, the padding between the candidate string and the annotation can also be arbitrarily large. Naive truncation that truncates the entire concatenated line against the width of the pop up box, which is actually the window width in a child frame, may leave some arbitrarily long empty space in the end. In addition, naive truncation does not replace extra characters in the relevant columns with ellipses to indicate truncation happened. Please look at the link in my first email for further details.
So the issue is not "pixel-wise truncation", the issue is to take
variable-width display elements into account when truncating, is that
right?
To be precise, by " truncate strings correctly and preferably in pixel precision", I mean truncation that respects pixel width constraints (and grapheme clusters, as clarified by you). Truncating variable-width display elements on GUIs necessitate the ability to calculate the widths of the individual elements, I call this the hypothetical `glyph-pixel-width`. Whether it is exposed to Elisp is less important to a hypothetical `truncate-string-to-pixel-width` for my use case.