|
From: | Ergus |
Subject: | Re: Question about display engine |
Date: | Mon, 19 Aug 2019 18:13:05 +0200 |
User-agent: | NeoMutt/20180716 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |