[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about display engine

From: Ergus
Subject: Re: Question about display engine
Date: Mon, 19 Aug 2019 18:13:05 +0200
User-agent: NeoMutt/20180716


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]