[Top][All Lists]

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

Re: Question about display engine

From: Eli Zaretskii
Subject: Re: Question about display engine
Date: Thu, 15 Aug 2019 18:18:32 +0300

> Cc: address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Thu, 15 Aug 2019 10:13:21 +0200
>  >> understanding face implementatin _without_ the text you wrote below
>  >> would take a couple of days at least for a humble reader like me.
>  >
>  > And I didn't even mention the complications related to bidi ;-)
> Are there any bidi complications related to that particular text?  No
> need for you to point anything out in detail: I suppose it's that
> finding the next "stop" position gets complicated when the display
> direction changes.

Exactly.  More accurately, we have 2 problems: (1) how do you know you
hit the stop point while going back; and (2) where do you go to
compute the "next" stop point.  You don't want to know the answers...

> Now in my naive imagination buffer text per se is
> one-directional so Fnext_single_property_change progresses always in
> one direction.  Does the inteval tree gets botched in some sense?

No, nothing terrible like that.  It's just those 2 problems mentioned

>  > It sill copies
>  > the :background attribute itself, and so the merged face will have a
>  > non-default background color.
> But isn't that the whole idea of that step?  Or do you mean that since
> the display engine can't cope with the extend bit and thus suppress
> the background by demand, doing that just won't have any effect?

The latter, yes.  IOW, doing that will simply defer the decision for

>  > So if the face ID of the last character specifies a face with a
>  > background color, and the extend_background bit says not to extend the
>  > background color, how would extend_face_to_end_of_line "remove" the
>  > background color attribute from the face for which it only has the ID?
>  >
>  > The only way to do that is to make a new face, by merging all the
>  > attributes except the background color, and then use that new face's
>  > ID for producing glyphs that extend the face.  This is why I said
>  > earlier that I assumed we make the extension decisions at face merge
>  > time, and will have 2 different realized faces, not one.  But you
>  > disagreed with that conclusion:
> ... I obviously have to discontinue disagreeing with that conclusion.
> But wouldn't that significantly increase the size of the face cache?

It will increase the cache, yes. Whether it will be significant is
another question; I'm not sure.

>  >> We should have only one realized face.
>  >
>  > AFAIU, that's impossible, not on the level on which
>  > extend_face_to_end_of_line (or any code in xdisp.c, really) works.  It
>  > cannot "apply a face sans some attributes", there are no such
>  > capabilities on this level.
> Since extend_face_to_end_of_line already switches to the default face
> when no extension of the region is wanted

It does? where?

> it could also switch to the default face when the extend_background
> bit is false.  Right?

No.  A face is not just its background color, it's quite a few other
things.  You only want to reset the background color.  For example, if
the face of the last character used a larger font, you still want the
extension to use that larger font, e.g. for the fill-column indicator

So switching to the default face in this case is wrong, we really need
to make a face exactly like the one we used, but without the attribute
that should not be extended.

reply via email to

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