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: Thu, 15 Aug 2019 18:18:32 +0300 Message-ID: <8336i2qwxj.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> <83woffrd7p.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17513"; 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 Thu Aug 15 17:18:52 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 1hyHWd-0004JM-DC for ged-emacs-devel@m.gmane.org; Thu, 15 Aug 2019 17:18:51 +0200 Original-Received: from localhost ([::1]:42940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyHWc-0005SM-7O for ged-emacs-devel@m.gmane.org; Thu, 15 Aug 2019 11:18:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36128) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyHWS-0005SF-7U for emacs-devel@gnu.org; Thu, 15 Aug 2019 11:18:44 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hyHWR-0006pA-Nv; Thu, 15 Aug 2019 11:18:39 -0400 Original-Received: from [176.228.60.248] (port=4748 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hyHWR-0003Zh-7W; Thu, 15 Aug 2019 11:18:39 -0400 In-reply-to: (message from martin rudalics on Thu, 15 Aug 2019 10:13:21 +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:239377 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Thu, 15 Aug 2019 10:13:21 +0200 > > >> 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 ;-) > > Are there any bidi complications related to that particular text? No > need for you to point anything out in detail: I suppose it's that > finding the next "stop" position gets complicated when the display > direction changes. Exactly. More accurately, we have 2 problems: (1) how do you know you hit the stop point while going back; and (2) where do you go to compute the "next" stop point. You don't want to know the answers... > Now in my naive imagination buffer text per se is > one-directional so Fnext_single_property_change progresses always in > one direction. Does the inteval tree gets botched in some sense? No, nothing terrible like that. It's just those 2 problems mentioned above. > > It sill copies > > the :background attribute itself, and so the merged face will have a > > non-default background color. > > But isn't that the whole idea of that step? Or do you mean that since > the display engine can't cope with the extend bit and thus suppress > the background by demand, doing that just won't have any effect? The latter, yes. IOW, doing that will simply defer the decision for later. > > 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: > > ... I obviously have to discontinue disagreeing with that conclusion. > But wouldn't that significantly increase the size of the face cache? It will increase the cache, yes. Whether it will be significant is another question; I'm not sure. > >> 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. > > Since extend_face_to_end_of_line already switches to the default face > when no extension of the region is wanted It does? where? > it could also switch to the default face when the extend_background > bit is false. Right? No. A face is not just its background color, it's quite a few other things. You only want to reset the background color. For example, if the face of the last character used a larger font, you still want the extension to use that larger font, e.g. for the fill-column indicator character. So switching to the default face in this case is wrong, we really need to make a face exactly like the one we used, but without the attribute that should not be extended.