Re: Question about display engine

[Ergus <spacibba@aol.com>]

Hi:

After a couple of weeks with this discussion I am back to see if there
 is finally an agreement or more people interested. But I see there are
 mainly only Eli and Martin involved. The proposed solutions I see here
 seems to be a bit complex (to implements and to execute for the display
 engine). It seems that no applications or developers are interested on
 this detail enough to comment or propose solutions here.

I understand that the proposed are the most general solutions, but does
 it worth the complexity, overhead, and customization vs the benefit? Do
 we really need all these functionalities and control in detail? Are we
 really expecting that the users will be allowed||interested in
 customizing all this in such granular level?

Extending the face is a detail that most users won't even notice a
change while it works somehow. Actually we have had different behaviors
between gui and tui for years and nobody complained up to now.

Extending the underline|overline to the right of the line in the region
is a fancy detail, but I don't find it useful at all (underlining empty
long spaces is conceptually an error), and in the actual gui it is not
happening (not even extend_face_to_end_of_line in gui is executed as the
background color is extended automatically somewhere else) and there
haven't been complains either, so there is not people using that, so why
do we provide a complex solution implementation for a problem nobody
really cares and that potentially will produce overheads, code
complexity and more issues?

I am wondering about over-specifications and over-engineering for such a
detail, when most of the users only need to extend the background color.

On Sat, Aug 17, 2019 at 10:25:13AM +0200, martin rudalics wrote:
>> I'd prefer this method.  Two reasons: (1) it is localized to the code
>> which may need such a face; and (2) it scales better, because the
>> display code is frequently invoked on short portions of the text, so
>> there's no guarantee that it will actually get to producing glyphs
>> with the "extension" variant of the face, so realizing that face in
>> advance might well be waste of unneeded effort, because the additional
>> face will never be used.
>
>The following should capture what emerged from this discussion so far:
>
>(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.
>
>(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.
>
>Conversely, we could use a :no-extend attribute and/or
>no-extend-background bits in the realized faces if that's simpler or
>more intuitive.
>
>martin
>