Re: Question about display engine

[martin rudalics]

> (1) Provide an :extend face attribute with the semantics to extend, if
>     set, any "background-related" attributes like :background,
>     :underline, :box ... specified by this face.
>
> The extend attribute here must be just a boolean to extend everything
> set in this class or something to specify what to extend from within
> this face?

The former, conceptually.  Only if we detect a corner case which tells
us that inevitably "more" is needed, it might become necessary to
implement the latter.  So it might be a good idea to have the values
unspecified, t, nil and a list where the semantics of a list would be
currently undefined.

> (2) When merging faces, set an extend-background, extend-underline,
>     extend-box ... bit for all background-related attributes whenever
>     the face merged in has both the :extend attribute non-nil and the
>     corresponding background-related attribute set.
>
> (3) When the display engine encounters a newline character and the
>     current face has one of the extend-* bits set, either reuse or
>     create a new realized face based on the current face, removing
>     from a new realized face any background-related information for
>     which the current face that has the corresponding extend-* bit
>     set.  For example, if the current face specifies a background,
>     remove that in the new face if the extend-background bit is unset.
>
> (4) Use the face found or made in (3) for glyphs on the rest of the
>     current line.
>
>
> 1- Are the bits stored in the class or they are supposed to be like a
> display engine state variable?

In the class, IIUC.  That is, when merge_face_vectors merges in "an
attribute we care about" it sets, for example, the extend_background
bit of the TO face when both the :extend and :background values of the
FROM vector are set.

> Check this true table please:
>
> merge_faces (struct window *w, Lisp_Object face_name, int face_id,
>              int base_face_id)
>
> struct face = {extend_flag; bg, extend_bg_flag}
>
> base_face -> face = merged
>
> {true, nil, false} -> {false, y, false} -> {false, y, true}    // ????
> {false, x, false} -> {true, nil, false} -> {true, x, true}     // Is this 
fine?

I'm too silly to understand these, please elaborate.

> When in 3 it says "remove", what does it means? set it to x, to default or
> to nil?
>
> In case we don't extend, the extra space we add after the line should
> have the default, face or the last in the line??

The term "remove" was meant wrt the current face used by the iterator.
If, for example, the current face of the iterator is the one specified
by the region face, then it probably specifies some background used
for "normal" text.  When the display engine arrives at the newline
character it checks whether the current face has the extend_background
bit set and either reuses an existing or realizes a new face based on
the background of the current face and that bit.

What realizing has to do when extend_background is false is not
entirely clear to me either.  Suppose we have a newline character that
is contained both in the region and a multiline comment and the region
face results in an extend_background false bit while the comment face
results in an extend_background true bit for the corresponding
realized faces.

Conceptually, this means that the spaces at the end of the line should
have the comment background but unless we expand the extend_background
bits into full pointers to other realized faces (and have face merging
set up these pointers and the display engine resolve them) I see no
way how this could be realized.  So the rest of the line would be
shown with the default face's background instead (or do whatever we do
now when we don't expand) which obviously won't look good.

Personally, I consider a setting like the above a misspecification: A
"lower priority extend" face should never result in being covered by a
"higher priority no-extend" face but others might obviously disagree.

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.
But I doubt that this would be easy to code.

martin