From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Wed, 14 Aug 2019 18:14:34 +0300 Message-ID: <83woffrd7p.fsf@gnu.org> References: <83k1bpasic.fsf@gnu.org> <20190807155738.yviofsumjjhqueci@Ergus> <83imr9ar9f.fsf@gnu.org> <0975890b-37b4-428d-f6e5-5dcf894fb6be@gmx.at> <83ftmdapxm.fsf@gnu.org> <20190808083804.ta3evocyb4hirywj@Ergus> <20190808145015.2qaxwzwf4ws2i3er@Ergus> <83ftm98dgu.fsf@gnu.org> <5361a037-d204-b746-790f-ee2ea09459e6@gmx.at> <83o90vu6ws.fsf@gnu.org> <831rxqtnaf.fsf@gnu.org> <7ba80ec4-d7e2-1f69-5b55-00a8c1851cb4@gmx.at> <83k1bhrsji.fsf@gnu.org> <6f3161f8-b007-ae1c-881e-1fad88348146@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="21325"; mail-complaints-to="usenet@blaine.gmane.org" Cc: spacibba@aol.com, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 14 17:15:58 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 1hxv0I-0005Px-7u for ged-emacs-devel@m.gmane.org; Wed, 14 Aug 2019 17:15:58 +0200 Original-Received: from localhost ([::1]:33268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hxv0H-0001wu-2g for ged-emacs-devel@m.gmane.org; Wed, 14 Aug 2019 11:15:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38797) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hxuz9-0001vl-41 for emacs-devel@gnu.org; Wed, 14 Aug 2019 11:14:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hxuz8-0004NG-1D; Wed, 14 Aug 2019 11:14:46 -0400 Original-Received: from [176.228.60.248] (port=4100 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hxuz7-0002lF-13; Wed, 14 Aug 2019 11:14:45 -0400 In-reply-to: <6f3161f8-b007-ae1c-881e-1fad88348146@gmx.at> (message from martin rudalics on Wed, 14 Aug 2019 10:58:13 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239359 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Wed, 14 Aug 2019 10:58:13 +0200 > > >> Consider a user who sets the :extend attribute to non-nil for the > >> 'default' face and wants a 'link' background to not extend to the end > >> of line. Such a user would want to set the :extend attribute of the > >> 'link' face to nil to get the desired effect. > > > > Yes, and my point is that in that case we can simply ignore the 'link' > > face when extending the face of the last character of a line. > > How would the display engine then know that it can "simply ignore" > the background of that face for the rest of the line? By seeing that it has the :extend attribute set to nil. > understanding face implementatin _without_ the text you wrote below > would take a couple of days at least for a humble reader like me. And I didn't even mention the complications related to bidi ;-) > > Neither :background nor any other face attribute is "found and > > applied" in the main iterator loop. The iterator simply records in > > each glyph the face ID to be used for displaying that glyph. That > > face ID is the value returned by the last call to > > face_at_buffer_position. > > IIUC the latter will (unless the face was cached already) end up > calling merge_face_ref and somewhere there I find the lines > > else if (EQ (keyword, QCbackground)) > { > if (STRINGP (value)) > to[LFACE_BACKGROUND_INDEX] = value; > else > err = true; > } > > Hence IIUC in the > > while (CONSP (face_ref) && CONSP (XCDR (face_ref))) > > loop we could manage three booleans background, extend and > extend_value and instead of the above write > > else if (EQ (keyword, QCbackground)) > { > if (STRINGP (value)) > { > to[LFACE_BACKGROUND_INDEX] = value; > > if (extend) > to[LFACE_EXTEND_BACKGROUND] = extend_value; > > background = true; > } > else > err = true; > } > else if (EQ (keyword, QCextend_background)) > { > extend = true; > extend_value = !NILP (value); > > if (background) > to[LFACE_EXTEND_BACKGROUND] = extend_value; > } This just copies the :extend flag to the merged face. It sill copies the :background attribute itself, and so the merged face will have a non-default background color. > > So you propose to have an "extend" bit for every face attribute? > > There are 18 of them. (Maybe some of the attributes won't need that > > bit, but quite a few will.) > > I'd propose to add these lazily if there is any need. AFAIAC > :background is the only attribute where an extend bit sounds useful. IMO, it makes very little sense to allow this only for the background color. For starters, please keep in mind that this whole discussion started because we were considering to make TTY frames behave like GUI frames wrt face extension, and TTY frames currently extend also the other attributes, notably the :underline. Some people also complain about :underline being ugly on GUI frames when it crosses the newline and continues on the next line. I think we need to support this for :background, :underline, :overline, :strike-through, :box, and :stipple. > The extend_background bit would be set in merge_face_ref as sketched > above (because this is the one that can read the :background and > :extend attributes of any face) and examined in > extend_face_to_end_of_line wherever face->background is involved > (because this is the one that knows that we want to display a > newline). What do you want extend_face_to_end_of_line to do with the extend_background bit? extend_face_to_end_of_line doesn't apply the background, it just produces glyphs, and has only face IDs to work with. So if the face ID of the last character specifies a face with a background color, and the extend_background bit says not to extend the background color, how would extend_face_to_end_of_line "remove" the background color attribute from the face for which it only has the ID? The only way to do that is to make a new face, by merging all the attributes except the background color, and then use that new face's ID for producing glyphs that extend the face. This is why I said earlier that I assumed we make the extension decisions at face merge time, and will have 2 different realized faces, not one. But you disagreed with that conclusion: > > What I wrote above assumed that > > we make these decisions at face merge time, and will actually have 2 > > different realized faces; > > We should have only one realized face. AFAIU, that's impossible, not on the level on which extend_face_to_end_of_line (or any code in xdisp.c, really) works. It cannot "apply a face sans some attributes", there are no such capabilities on this level.