Re: Question about display engine

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Fri, 30 Aug 2019 09:03:06 +0200
> 
>  >> But where do we get that from?
>  >
>  > It will come out automatically from the face merging process.
> 
> You told me before and I'm still afraid that no such automatism
> exists.

It happens as part of face merging.  The attribute that doesn't get
merged causes the same attribute of another face to become the
attribute of the merged face.

>  >> But when the display engine gets there, the respective face was not
>  >> even realized.
>  >
>  > It will be realized when the display engine comes to that place.
>  > That's exactly what we have been talking about here, right?  Or maybe
>  > I don't understand what difficulty you are seeing there.
> 
> But then "realizing" the face for the spaces at the end of line
> becomes much harder: The display engine has to handle _every newline_
> in every buffer as _if it were a stop position_ in order to merge all
> faces at that position and find out which background to use.

I thought we already agreed that there's no other way of having this
feature than to realize a face at each EOL.

>  >> The merging process will kick in iff we treat the newline character at
>  >> the end of line 2 as a stop position.  Since no text property changes
>  >> there, I don't see how this could happen.
>  >
>  > It will happen because we call append_space_for_newline and
>  > extend_face_to_end_of_line, and those functions _know_ they are at end
>  > of a line.
> 
> But they would still have to fully realize the face to use by merging
> all faces at each newline.  This means we can do away with all those
> precalculated extend_background, extend_... bits because they cease to
> contribute anything to the solution.

I don't think I understand what the "precalculated" part refers to.

> The only practical solution I see is to, instead of extend_background
> bits, use extend_background colors.  In my example, this would mean
> that when, at the stop position prescribed by the comment start text
> property change, the face merger sets the background value of the face
> to realize to that of the region and the extend_background value of
> the face to realize to that of the comment.  The display engine would
> then realize the face for writing the remainder of the line right from
> extend_background instead of from background + extend_background.

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.

>  > Maybe I don't understand the question, because I see no problems
>  > here.  Just coding.
> 
> Maybe you're right.  But I still don't see the light at the end of
> this tunnel.

I don't think I see the tunnel.  I thought the issue was resolved when
you posted your summary up-thread.  What am I missing?