Re: Question about display engine

[martin rudalics]

> I have been thinking about this a little bit more and it seems like we
> are trying to replicate a behavior that is already there.
>
> If we had an extra face pointer within the face struct initialized to
> null (or default face), and then when we merge and the extend attribute is 
set we
> initialize it to the current merged face and we transmit that pointer
> from merge to merge until we have a new face with :extend, so we merge
> then those two... I think when we reach the end of the line we will
> have there already all the information we need.
>
> Lets say we have a sequence of consecutive merges (a,b,c,d,e); but only
> b and d have :extend.
>
> At the end we will have in the merges:
>
> (a, a+b, a+b+c, a+b+c+d, a+b+c+d+e)
>
> but with this pointers in them:
>
> (nul, b,     b,   b + d,     b + d)
>
> Which for me it seems to be what we expect to have right?
>
> Does it makes sense?

I think so.  Now the realized face for normal text is a+b+c+d+e and
the display engine would use it right away.  When the display engine
encounters a newline character it has to "switch" from a+b+c+d+e to
b+d.  But it has to assure that b+d _is a realized face_ because a
reference to that face is the output expected from the display engine.
Any additional pointers like yours would be ignored after that.

Do you agree so far?  If so, then the question remains _when_ to
realize b+d.  Eagerly, when the face merger has done its work, or
lazily when the display engine encounters the newline.  Eagerly has
the advantage that the display engine has all the faces already
realized.  Its disadvantage is that when a new stop position is found
before the EOL, the b+d face was realized needlessly.  Do you still
agree?

If so then we might consider the following optimization: The extra
face pointer in each face is no more needed after the display engine
has processed the face.  So we could build a "shadow" face for b+d,
keep it in a separate, static face structure and realize a face from
that structure whenever we want to (eagerly or lazily).  The display
engine, when it finds a pointer to such an extra face at EOL, uses it
(maybe realizing it on the fly).

Also, the merger could nullify the extra face if it's the same as the
normal one, that is no single merge step had an :extend false value
override a former :extend true value.  So the display engine would
know beforehand that it does not have to change the current face.

Last but not least, the display engine has to, after processing the
spaces at the EOL from b+d, restore the a+b+c+d+e face as its current
face.  So we have two static pointers to keep around: One for the b+d
face structure (or its already realized face) while the display engine
processes normal text and one for the a+b+c+d+e realized face while
the display engine processes the spaces at EOL.  Can you still agree?
Can you imagine any difficulties with implementing such an approach?

And we would have happily put to rest all those crazy extend_... bits
I proposed earlier.

martin