[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: Sun, 15 Sep 2019 23:42:35 +0200
User-agent: NeoMutt/20180716

On Sun, Sep 15, 2019 at 06:32:12PM +0300, Eli Zaretskii wrote:
Date: Sat, 14 Sep 2019 22:42:07 +0200
From: Ergus <address@hidden>
Cc: address@hidden, address@hidden

>I implemented this in the face_at_buffer_position but in the same
>function (handle_face_prop_general) there is a function called
>face_at_string_position equivalent to face_at_buffer_position... is it
>possible in some conditions to reach that part of the code at eol? if
>so I will need to modify that one too maybe right?

Yes, it's possible.  You need to arrange for a display string or an
overlay string with en embedded newline.

Done, new commit uploaded
>The filter now in merge_ref only works when !CONSP(ref_name). As it only
>bypass the extra parameter to merge_named... it this right in the
>general case?

I think we should support all the cases, otherwise the feature will
behave inconsistently, and we will get bug reports.

About this; the problem is that in the general case I'm not sure what's
the "right" behavior for the other cases. When !CONSP(ref_name) it means
that the parameter is a face_name; but in the other cases it means that
we are explicitly specifying the attributes as a cons list or as
:atribute value pairs... What's expected to happen in those cases??

Could you suggest (if any) if there are some conditions we can use to
avoid the call to handle_face_prop_general in some cases?

Why, did you see any tangible slow-down of redisplay due to these

reply via email to

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