Re: Question about display engine

[Ergus <spacibba@aol.com>]

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