Re: Question about display engine

[Ergus <spacibba@aol.com>]

On Fri, Sep 06, 2019 at 09:12:06PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 6 Sep 2019 18:34:56 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: rudalics@gmx.at, emacs-devel@gnu.org
>>
>> 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.
>

Hi Eli:

In your solution I am facing an issue that I am not sure how to solve:

I added a function handle_face_prop_general; that I call in
extend_face_to_end_of_line but I get an inf loop because in the call
stack I have:

extend_face_to_end_of_line
handle_face_prop_general
face_at_buffer_position
Fget_text_property
Ftext_properties_at
validate_interval_range

That has a condition:

if (!(BUF_BEGV (b) <= XFIXNUM (*begin)
     && XFIXNUM (*begin) <= XFIXNUM (*end)
     && XFIXNUM (*end) <= BUF_ZV (b)))
	args_out_of_range (*begin, *end);

And for some reason:

XFIXNUM (*end) <= BUF_ZV (b) is false; so the function args_out_of_range
emits a signal and never returns.

It is possible that in the first calls to extend_face_to_end_of_line the
BUF_ZV (b) is not initialized yet? Because it is always 1. when I print
it.