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 17:49:27 +0100
> Cc: emacs-devel@gnu.org
> 
>  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.

OK, but then the Lisp program which produces that bar knows its
pixel-width, and can account for it in the :align-to spec.

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

Why would you need to truncate? and which part needs to be truncated?

My suggestion is to align the <Type>s part so that it and the
following pseudo-scrollbar end exactly at the window edge.  With this
arrangement, you shouldn't need to truncate at least the <Type>s part.
This can be dome by using :align-to which counts from 'right', which
is the right edge of the text area.

Actually, I don't understand why you'd need to truncate anything,
since the dimensions of the child frame can be calculated such that
the longest completion candidate will still fit without truncation.
Or what am I missing?

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

You assumed something I didn't say and didn't have in mind.  There
should be no need to use truncate-lines.

>  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 don't think you fully understand the code you are referring to,
because it will not do what you want.  E.g., check_display_width calls
string-width, which you found problematic, and image.c doesn't handle
layout of images.  More importantly, the _only_ place in Emacs where
we have code that lays out glyphs until it hits some specified
coordinates is in the display engine, where it arranges text for
display, one "display element" at a time.  Exposing that to Lisp in a
useful way is a hellishly hard job, because that code was never meant
to be useful from a Lisp program, and from a POV of a Lisp programmer
in certain cases behaves nonsensically.  That's one of the reasons why
vertical-motion has such a complicated implementation which deals with
half a dozen different complications when using the display code in
such way.

Of course, if someone wants to write such a code, and it will be clean
and correct, such patches will be welcome.  But please believe me when
I tell you that it is much better to try to avoid that and use
existing display capabilities (which will also allow you to support
this in current Emacs versions, instead of waiting for some future
one).

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

This is not about refusal.  It isn't like what you are asking is easy
to do, and the "Emacs devs" are just a lazy bunch.  I looked at the
code involved, and I currently have no idea how to implement what you
have in mind so that it works in all the cases, those which you
mentioned and those you didn't, and works in a way that will be useful
for Lisp programs.  You may think it's easy, but it isn't.  Some
things are even conceptually not simple, for example whether it is
okay or not to break a string between U+1F3C2 and the following
U+1F3FF, and if so, how to discover that subject to how the current
character-composition machinery in Emacs was designed and implemented.

Of course, it is possible that I'm missing something, so if someone
has ideas about implementing this, let alone code, I'm all ears.

But even if such ideas/code emerge, I think doing this job using
existing display capabilities is a better way, because it will work
immediately with existing Emacs versions, and will probably be more
reliable.  I still don't see why you couldn't solve the problem using
:align-to and the other ideas I suggested.

Last, but not least: please don't forget that Emacs is a
volunteer-driven project, and the only resources we have are those of
people who decide they want to work on something, for whatever
reasons.