Re: Question about display engine

[Ergus]

On Wed, Aug 28, 2019 at 02:19:03PM +0200, martin rudalics wrote:
> > I think we should simply not merge the background color of the region
> > face when its extend bit is reset.  Then the merged face will not have
> > that background color.
>
> Then which background color would we use?  That of the comment was
> lost when setting up the current face for the iterator.
>
> > I don't see a problem here.  A user who doesn't want the region face's
> > background extend to the end of line wants only text (as opposed to
> > whitespace after the newline) to have the region's background, and
> > that's true both to regions that cross line boundaries and regions that
> > end at a newline.
>
> I agree that we don't want to extend the region's background.  But the
> question I raised above still stands.
>
> We could make :extend sticky in the sense that once an :extend for the
> background has been defined, it will apply to all higher priority faces
> as well.  This would make specifying a nil :extend value idempotent to
> not specifying a value at all as you (IIRC) proposed earlier.  But the
> mechanism then becomes considerably less powerful.

Any way my question comes from 2 frequent use cases I don't know what's
the expected behavior:

1) Base face sets background and extend; and face sets only background.

2) Base face sets extend but not background; and face sets both.

in what condition the :extend attribute goes to the merged face? Always?
when in base_face? When in face?

in what condition the extend_element bits are reset after a merge? 

> > > Maybe the display engine could consult, with the stop position
> > > privilege triggered by the newline character in mind, whether the
> > > extend_background false setting of the current face could result in
> > > applying another, lower-priority face specified by font-locking and
> > > consult the extend_background bit of the corresponding realized face.
> >
> > I don't think I understand this proposal.
>
> Let's talk about it when we both see a problem here.
>
> martin