Re: Question about display engine

[martin rudalics]

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

> This just copies the :extend flag to the merged face.

Yes.

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

> I'd propose to add these lazily if there is any need.  AFAIAC
>> :background is the only attribute where an extend bit sounds useful.
>
> IMO, it makes very little sense to allow this only for the background
> color.  For starters, please keep in mind that this whole discussion
> started because we were considering to make TTY frames behave like GUI
> frames wrt face extension, and TTY frames currently extend also the
> other attributes, notably the :underline.  Some people also complain
> about :underline being ugly on GUI frames when it crosses the newline
> and continues on the next line.

That's why in a first step I would disregard the others and by default
not extend them.  Then we would see what is missing and fill in the
remaining attributes of this list ...

> I think we need to support this for :background, :underline,
> :overline, :strike-through, :box, and :stipple.

... to possibly extend to end of line as well.

> What do you want extend_face_to_end_of_line to do with the
> extend_background bit?  extend_face_to_end_of_line doesn't apply the
> background, it just produces glyphs, and has only face IDs to work
> with.

Since I wasn't aware of that fact ("I'm learning something new about
Emacs almost every day") ...

> 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?
I have no idea about the typical size of that cache with a moderately
customized Emacs ...

>>   > What I wrote above assumed that
>>   > we make these decisions at face merge time, and will actually have 2
>>   > different realized faces;
>>
>> 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 could also switch to the
default face when the extend_background bit is false.  Right?

martin