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.