From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Mon, 19 Aug 2019 18:13:05 +0200 Message-ID: <20190819161305.uwlgsm44yjrmul3o@Ergus> References: <831rxqtnaf.fsf@gnu.org> <7ba80ec4-d7e2-1f69-5b55-00a8c1851cb4@gmx.at> <83k1bhrsji.fsf@gnu.org> <6f3161f8-b007-ae1c-881e-1fad88348146@gmx.at> <83woffrd7p.fsf@gnu.org> <8336i2qwxj.fsf@gnu.org> <020947f5-a8ab-79de-cf74-9dce4cb1572e@gmx.at> <838srtpkyp.fsf@gnu.org> <471528b0-4749-1dee-3be1-fa18a0203cc7@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="239192"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 19 18:14:11 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hzkIM-00106e-VI for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2019 18:14:11 +0200 Original-Received: from localhost ([::1]:54964 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzkIJ-0001TD-J3 for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2019 12:14:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34641) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hzkHU-0001T6-N7 for emacs-devel@gnu.org; Mon, 19 Aug 2019 12:13:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hzkHS-00040W-Uz for emacs-devel@gnu.org; Mon, 19 Aug 2019 12:13:16 -0400 Original-Received: from sonic301-22.consmr.mail.ir2.yahoo.com ([77.238.176.99]:46027) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hzkHS-0003z9-Ej for emacs-devel@gnu.org; Mon, 19 Aug 2019 12:13:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1566231192; bh=EUNV8yLYmuWFnEkoAY1YqpH2U0gbKFnMfMppHkL+mR8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=MYDOMLTS9+SD9+TGUgFMNaU7Yx989I9MKLo6XxgP4bYlHjlNyt6TJweUfueERsfYbLk7jZIqzOg6tEE2EaPim0kDqqVXSGeocZ4oZBJqu/hEFXxDZk8P6FGwJSMLqu6cFKFLSnEBPeq/I+iHaEuRtmrghuJG3/pWxR0yBYpyRpJX+vq8/TO8eZL0OmABrxWpFhOLqkC9h8fqAgngG3PDQ79n/g1ewuuy5R8mcMILyKRHLOUBmMkODPNfmzfNnAnSShxvhIQkP+x9rMMRdjV8Nv6T4H6G1M0UYp1AjMkKkzu+4KJX7IJs6d9JCgDvncpG44lWUZyaV0r/2uBaLBuRmA== X-YMail-OSG: OLjtg9sVM1lqCdLrAfq9om1mBztgkULqOcQJO6NiBnyOFK.x4u4ZcZTlcyAf48q Za1FbtOs6.Yh0CR1yXrxz.Gqg57mMouFvOImrW8z6QIYNuVhn1y2aL_AFXCB_65L4UbnSzvrLyBL Oez5XxJT11T4JglhR2wW0723kX9ek2T0CJqjpFL6Hv5BC9Ind_IEKl3XnmUIQF5ARKv3rydLEA2Q VeiohFZqrwkkhBnQyMiLcOEE6LkZxgvHS2EJzQ2x.xCV25weNkpbOTJB4m1Q4WwxQ_GlY2e3oDYF qSC7YUGtx8fHn0OU.kTUKozHDRkgI6dlIsMd2s_BGq0QuWU6P01Of40cIkq_fBPOuunMJwoUCoIi nVvKXws5QPEMB1B3OOnN8XU1ymryHNZsBCXgYEB2pihHxFKv1Kfiss4rzw7DKz5ucnq2WxijFqOA IbTBMzqmPU5FzaSsBIjMsCRrOZLw37zF3pPW4FbGEIP9ZEfV7D85HCyrJXU3qi.kqJ3g9zNfnFQl deJTTg7os7ePz_WGOhHX3aonp57zwqBfNBIwTZmXg1L3T84_0ZW8Ss.FRKNTKHS8A26UU2BfdHSs r2pZWCr7sAdpQdb1JRPYUNKKEgs0RPdehSYpCu94uad1G0yRpcl2LhMlOmeZ0M.8J5wAuUg2Txb9 fTwfbKPgL6uhRixiDSDBxZqQno9cG1PRaq4.woRpizVr.SxQcw2dyBGNKlF1tuMu7iHnLeOlZRfR 1us1rBVMCiVAGx3vqnNB0tZq60NiuehU1Jo4696tu39M1v7RiYv0fWIJyyO7pOlx21WvS2b.d9dG PIQENStQPq3gxBvkTC.kinau8J233COnlq3R7RYj8P Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ir2.yahoo.com with HTTP; Mon, 19 Aug 2019 16:13:12 +0000 Original-Received: by smtp418.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ff059eba23afbb02d93f9a6905ef1e69; Mon, 19 Aug 2019 16:13:08 +0000 (UTC) Content-Disposition: inline In-Reply-To: <471528b0-4749-1dee-3be1-fa18a0203cc7@gmx.at> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.176.99 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239462 Archived-At: 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 >