Re: Question about display engine

[Eli Zaretskii]

> Date: Fri, 6 Sep 2019 18:34:56 +0200
> From: Ergus <address@hidden>
> Cc: address@hidden, address@hidden
> 
> When you say a variant you mean another function to call directly from
> extend_face_to_end_of_line?

Yes.

> Sorry I still don't understand where is (a +
> b + c + d) computed or where emacs "remembers" that, or if it is
> computed all the time. But maybe the trick is actually in
> face_at_buffer_position, face_for_overlay_string or
> face_at_string_position?

face_at_buffer_position and face_at_string_position collect all the
faces that affect a given buffer/string position, and then they merge
these faces to produce the face ID to be used by the iterator.  By
"remember" I meant that if you call face_at_buffer_position for any
position between stop positions A and A+1, it will produce the same
face ID, because the face properties don't change between stop
positions.  The data structures maintained by Emacs that determine the
faces in effect for a particular position is what "remembers" these
faces for you.

> If so; then what we really need is a variant of face_at_buffer_position
> like extend_face_at_buffer_position? (or add to it a parameter to do
> what we want) does it makes any sense.
> 
> handle_face_prop can't be modified as it should have a specific
> prototype. But we can make it a wrapper and create a generalized or use
> ITERATOR_AT_END_OF_LINE_P internally?

What I meant is to write a function like handle_face_prop, but one
that instructs face_at_buffer/string_position to merge the relevant
faces in a special way, one that takes the :extend attribute into
account.  Whether the code will be similar enough to what
handle_face_prop does now to make them use the same code, is a
separate question; I wouldn't be bothered by that at this time.  First
let's have code that we understand and that works; we can bother about
cleaning up and optimizing later.