Re: Question about display engine

[Ergus]

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
> changes?