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"?
That thin white bar on the right of the box from the third screenshot onwards is actually a string with a display space property in pixels, not a real scroll bar.
Using :align-to in the padding between the candidate and annotation is not a problem, the problem is if the concatenated line is too long, I'll need to truncate. There are 2 options - `truncate-string-to-width`, which is bugged, or set the `truncate-line` buffer local to t and let Emacs' window system do its magic, which will be performant and correct, and I can even replace the arrow in an ellipsis, but truncation will start to truncate off the emulated scroll bar.
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.
As I described in my first email, this can almost be achieved from the existing Elisp functions and C functions exposed Elisp. The performance problem associated with resolving a font WRT the anonymous face and face list craziness can be done in C, and already exists. The width of the display space and string replacement text properties can be calculated by `check_display_width` in `indent.c`, and rest is surely somewhere in `image.c`. I hope you are not telling me that Emacs devs still refuse to give people the ability to align text in pixel precisions programmatically at the end of 2024. Browsers have had this ability for almost 30 years.