Re: Question about display engine

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Sat, 31 Aug 2019 09:29:13 +0200
> 
>  > I thought we already agreed that there's no other way of having this
>  > feature than to realize a face at each EOL.
> 
> Then that's where we have been miscommunicating.  The whole idea
> behind the extend_background, extend_underline, ... bits was to avoid
> the full handle_stop rigmarole at EOL, like finding the overlays and
> text properties and processing them in the right order.

We don't need everything from handle_stop, we only need the parts that
affect the face.

> The only missing step is to process the :extend attribute of any face
> merged.  For the normal background, this is the value of the
> :background attribute of the last face that specified that attribute
> and was merged in.  For the extended background this is the value of
> the :background attribute of the last face that specified that
> attribute, had the :extend attribute set and was merged in.
> 
> 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.

> If we wanted to realize both faces - the one to use for the current
> face and the one to use for extension - immediately (eagerly as I
> coined it earlier), we could do that right after merging terminates.
> We probably would set up a pointer to the realized face to use for
> extension, so the iterator, when arriving at EOL, would find it right
> away and make it current.  That's all.
> 
> But we probably don't want to realize the face to use for extension
> immediately and do it - as we agreed earlier - lazily when the
> iterator arrives at EOL.

If lazy realization is hard to implement, there's nothing wrong with
realizing both faces immediately, at each stop position.

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

>  > I don't see how this will help anything.  To remind you: the display
>  > engine manipulates face IDs, it doesn't know anything about the faces
>  > themselves, and in particular cannot magically exchange a face's
>  > background color for some other color.
> 
> But it knows where the background of a realized face is stored and
> could easily realize a new face which is the same but for a different
> background swapped in.  Hardly rocket science for the display engine.

If we extend faces to keep the information about how to do that, then
yes, this can be done.

> So what we could do is to simply maintain a vector of the values for
> background, underline, etc. calculated at the last real stop position
> and whenever the display engine encounters a newline, realize a face
> with the values of that vector replacing the current values, use that
> face for the spaces at the rest of the line, and restore the old face
> for the normal text on the next line (unless we have several newlines
> in a row and similar optimizations).

That's possible, assuming faces are extended as mentioned above.  But
I'm not sure realizing both faces immediately ("eagerly") will not be
an easier solution.

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