[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about display engine

From: Ergus
Subject: Re: Question about display engine
Date: Sat, 7 Sep 2019 04:35:44 +0200
User-agent: NeoMutt/20180716

On Fri, Sep 06, 2019 at 09:12:06PM +0300, Eli Zaretskii wrote:
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


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

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:


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]