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

[Eli Zaretskii <eliz@gnu.org>]

> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Thu, 24 Oct 2024 16:33:14 +0100
> Cc: emacs-devel@gnu.org
> 
>  If the scroll bar and the margin are generated programmatically, then
>  presumably the program which creates them knows their width, or can
>  calculate that?  If so, the :align-to value should take that into
>  consideration.
> 
> As I said, the problem is letting the window system do the truncation rather than in code. There's no way to
> tell Emacs to start truncating from the actual content rather than UI elements that Emacs thinks are content.

I guess I don't understand the issue you are describing.  Where does
window system come into play here?  What are "UI elements that Emacs
thinks are content", and where are they in the screenshots shown in
https://github.com/minad/corfu/pull/508 ?  And where in my suggestion
did I propose anything that would cause "truncation by window system"?

> Hence, the original ask. Correct and performant custom truncation that respects pixel width is much much
> harder than it should be in Emacs.

Lisp programs are not supposed to do layout calculations, plain and
simple.  The reason is that layout calculations are impossible without
having a window with lots of stuff that determines how text is
displayed.  So doing that on strings is meaningless.

Therefore, I'm trying to help you do the job using the existing
display facilities, because the kind of solution you have in mind is
unlikely to emerge.  If you want me to keep coming up with ideas,
please help me understand better the issues you are describing.  I
hope you do realize that to suggest viable solutions, I need to have a
good understanding of the problem.

But if my suggestions and questions annoy you, I can easily stop.