Re: Pixel-based display functions

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sun, 01 Feb 2015 01:28:16 -0500
> 
> > Or maybe I don't understand which functions you want to expose, so
> > please elaborate.
> 
> I just don't want Elisp code to compute pixel sizes based on
> glyph info.  It's what the C code already does.  So whenever Elisp code
> tries to do that, it's a mistake (not so much because we should do it
> in C, but because we end up having to reproduce in new code what
> existing code already does, which is exactly what's going on with this
> whole discussion about guessing which chunks of text will use the same
> font and how we should handle chars which aren't covered by the font
> etc...).

I don't think Lars's Elisp does what the display engine does.  It's
close, but different enough to warrant a different approach.  See
below.

> IIUC in the case at hand, the function which Lars needs is slightly
> different from what we already expose.  Instead of
> pixel-size-of-chunk-of-text, we want to have position-of-pixel-in-text
> (i.e. you pass a chunk of text, along with a pixel position, and it
> returns the position of that pixel in the text).  I.e. something more
> like vertical-motion (which receives a pixel horizontal coordinate and
> figures out where that is in the text).

I explicitly mentioned vertical-motion in one of my previous messages,
and explained there how to use it to find buffer position that
corresponds to a given pixel coordinate.  Lars said it wasn't what he
needed, I don't know why.  I assume he will be able to explain that.
If he can use vertical-motion, that's fine with me.  If not, your
position-of-pixel-in-text suggestion will suffer from the same
problem.

I also briefly considered writing a primitive such as
position-of-pixel-in-text, but eventually decided against it, because
I don't think that's what Lars needs.  Here's why.

First, Lars has no "text" in the sense that there's no buffer text to
render.  What he has is a _spec_ for the layout, in the form of HTML.
That spec provides a bunch of strings that need to be rendered under
certain constraints, but these strings are not inserted into any
buffer by the time the code we are discussing runs, and the move_it_*
functions we use in vertical-motion and elsewhere won't help us,
because they do need a buffer to iterate over.

(Of course, he could insert each string into a scratch buffer, but
that's a waste, and doesn't solve the other problem, described below.)

Second, there's a subtlety in move_it_* functions that was never
explicitly raised in this discussion, but which becomes rather
important if you want to consider reusing the move_it_* functions for
this use case: they produce glyphs in the _visual_ order.  So if the
text to be rendered includes R2L characters, you might break text
between screen lines incorrectly.  (If this isn't clear enough, I can
elaborate.)  Also, you will have to deal with the situation where
(position-of-pixel-in-text FROM TO) is _less_ than
(position-of-pixel-in-text FROM (1- TO)).  That is a complication that
Lars would surely like to avoid, I presume.  By contrast,
font-get-glyphs works in the logical order.