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, 29 Aug 2019 21:36:10 +0300 Message-ID: <83zhjrakf9.fsf@gnu.org> References: <20190819161305.uwlgsm44yjrmul3o@Ergus> <83pnl1kskj.fsf@gnu.org> <20190819213024.ciukp34xmgrzh7yn@Ergus> <83imqskjyb.fsf@gnu.org> <20190825102205.rxhmu3bukraywhok@Ergus> <83lfvhh6dn.fsf@gnu.org> <20190826043145.pm5aplrxna5hwcso@Ergus> <83y2zgfjzs.fsf@gnu.org> <20190826081819.cuhm3tpw3lq3m5jh@Ergus> <83mufwfe8o.fsf@gnu.org> <20190827222025.p2cbjwak4ysi3ept@Ergus> <3ea328a6-2b35-5a01-77a1-bbf9ff7f16f2@gmx.at> <83lfvdd5f7.fsf@gnu.org> <83woexb3yu.fsf@gnu.org> <160dfd3f-60d4-8758-df65-2165c552f39e@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="99341"; 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 29 20:42:15 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 1i3PN8-000Pjg-A1 for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 20:42:14 +0200 Original-Received: from localhost ([::1]:53442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3PN7-0006rm-7b for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 14:42:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46280) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3PH9-0002rz-T7 for emacs-devel@gnu.org; Thu, 29 Aug 2019 14:36:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i3PH9-0007Yp-Ie; Thu, 29 Aug 2019 14:36:03 -0400 Original-Received: from [176.228.60.248] (port=3049 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i3PH8-0003nc-OJ; Thu, 29 Aug 2019 14:36:03 -0400 In-reply-to: <160dfd3f-60d4-8758-df65-2165c552f39e@gmx.at> (message from martin rudalics on Thu, 29 Aug 2019 09:45:50 +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:239687 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Thu, 29 Aug 2019 09:45:50 +0200 > > >> > I think we should simply not merge the background color of the region > >> > face when its extend bit is reset. Then the merged face will not have > >> > that background color. > >> > >> Then which background color would we use? That of the comment was > >> lost when setting up the current face for the iterator. > > > > The one that was there before the region was activated. > > But where do we get that from? It will come out automatically from the face merging process. > Consider a three lines C buffer with > code on the first line and a two-line comment covering the remaining > lines with the region covering the entire buffer. Hence, the spaces > following the comment on the second line should be drawn with the > background of the comment face. The comment face doesn't have a background, btw. And for a good reason. But I digress. Maybe. > But when the display engine gets there, the respective face was not > even realized. It will be realized when the display engine comes to that place. That's exactly what we have been talking about here, right? Or maybe I don't understand what difficulty you are seeing there. > > Which one is > > that will be determined by the order in which the merging process > > merges the faces, and by the faces themselves -- whether they do or > > don't define a background color, and whether they do or don't have the > > :extend bit set. > > The merging process will kick in iff we treat the newline character at > the end of line 2 as a stop position. Since no text property changes > there, I don't see how this could happen. It will happen because we call append_space_for_newline and extend_face_to_end_of_line, and those functions _know_ they are at end of a line. > >> I agree that we don't want to extend the region's background. But the > >> question I raised above still stands. > > > > Did I answer it now? > > If so, I didn't understand the answer yet. Maybe I don't understand the question, because I see no problems here. Just coding.