Re: Question about display engine

[Ergus <spacibba@aol.com>]

Hi Marting and Eli:

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?

On Sun, Sep 01, 2019 at 10:14:06AM +0200, martin rudalics wrote:
>>> To put this into praxis, the face merger would maintain a shadow copy
>>> of the background value.  That shadow value would not get overwritten
>>> when merging in the :background attribute of a face that does not have
>>> the :extend attribute set.  Eventually, we would wind up with two,
>>> possibly distinct values of the background to realize - one for the
>>> normal and the shadow value for the extended background.
>>
>> The face merger doesn't maintain any state, so I don't think this is
>> easily done.
>
>The background would be stored in an extend_background slot of the
>face vector (or maybe even a separate extend_vector) which would
>contain the part of the state responsible for handling the background.
>
>>> Note: We could also try to find out whether there _is_ another stop
>>> position before the next EOL after merging faces and, if there's none,
>>> realize the extended face eagerly, but I'm not sure whether this idea
>>> can be incorporated easily.
>>
>> Right.
>
>IIUC next_interval is newline agnostic.  The 'auto-composition-mode'
>check does look for a newline within the next 1000 characters (around
>line 3761 of xdisp.c) so we maybe could use that.
>
>>> BTW: One problem with Ergus' proposal is that hacks like the one
>>> proposed for Bug#15934 won't work any more.  For that bug, we could
>>> obviously set the :extend attribute of the respective highlight line
>>> face but all instances in the wild using the same hack already would
>>> be affected by our change.
>>
>> Yes, of course.
>
>So we should probably provide a :no-extend attribute, extend face
>attributes by default and explicitly not extend some attributes like
>underline and box.
>
>martin
>