>
> 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.