Re: Need `truncate-string-to-pixel-width` and `glyph-pixel-width` functions in C

[Eli Zaretskii]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Wed, 23 Oct 2024 14:52:53 +0100
> Cc: emacs-devel@gnu.org
> 
> On Wed, Oct 23, 2024 at 9:01 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  I know next to nothing about Corfu, so I have hard time understanding
>  what you are trying to do and why.  Basically, the Emacs display
>  engine already truncates stuff it displays, so it is completely
>  unclear to me why you'd need to do that in Lisp.
> 
> Corfu is like Company, it's a completion frontend that formats a list of 
> completion candidates to fit inside a
> confined pop up box.

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?

> A `truncate-string-to-pixel-width` function is needed because propertized 
> strings may consist of display space
> text properties, images, emojis in a different font, and faces in variable 
> fonts, which all affect glyph widths, you
> can't simply assume every glyph will take up 1 column. As a result, when you 
> calculate some `end-column`
> and whether it has reached the width constraint in pixels, one would 
> necessarily need to know the exact width
> in pixels for each glyph. Converting the width constraint in pixels to 
> columns in order to supply it as the second
> parameter to a correctly implemented `truncate-string-to-width` amounts to 
> the exact same procedure.
> Therefore, either a `truncate-string-to-pixel-width` or `glyph-pixel-width` 
> function is needed, because
> `string-pixel-width` is very expensive.

So the issue is not "pixel-wise truncation", the issue is to take
variable-width display elements into account when truncating, is that
right?