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: Fri, 30 Aug 2019 11:48:45 +0300 Message-ID: <83mufr9gya.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> <83zhjrakf9.fsf@gnu.org> <2aff0873-5d18-a4a0-eada-1ad0e632e753@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="25776"; 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 Fri Aug 30 10:49:57 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 1i3cbT-0006Up-0f for ged-emacs-devel@m.gmane.org; Fri, 30 Aug 2019 10:49:55 +0200 Original-Received: from localhost ([::1]:57220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3cbR-0005Ei-8v for ged-emacs-devel@m.gmane.org; Fri, 30 Aug 2019 04:49:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49943) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3caD-0005EQ-C3 for emacs-devel@gnu.org; Fri, 30 Aug 2019 04:48:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i3caC-0007R7-Qi; Fri, 30 Aug 2019 04:48:36 -0400 Original-Received: from [176.228.60.248] (port=3503 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i3caC-0007rw-58; Fri, 30 Aug 2019 04:48:36 -0400 In-reply-to: <2aff0873-5d18-a4a0-eada-1ad0e632e753@gmx.at> (message from martin rudalics on Fri, 30 Aug 2019 09:03:06 +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:239696 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Fri, 30 Aug 2019 09:03:06 +0200 > > >> But where do we get that from? > > > > It will come out automatically from the face merging process. > > You told me before and I'm still afraid that no such automatism > exists. It happens as part of face merging. The attribute that doesn't get merged causes the same attribute of another face to become the attribute of the merged face. > >> 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. > > But then "realizing" the face for the spaces at the end of line > becomes much harder: The display engine has to handle _every newline_ > in every buffer as _if it were a stop position_ in order to merge all > faces at that position and find out which background to use. I thought we already agreed that there's no other way of having this feature than to realize a face at each EOL. > >> 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. > > But they would still have to fully realize the face to use by merging > all faces at each newline. This means we can do away with all those > precalculated extend_background, extend_... bits because they cease to > contribute anything to the solution. I don't think I understand what the "precalculated" part refers to. > The only practical solution I see is to, instead of extend_background > bits, use extend_background colors. In my example, this would mean > that when, at the stop position prescribed by the comment start text > property change, the face merger sets the background value of the face > to realize to that of the region and the extend_background value of > the face to realize to that of the comment. The display engine would > then realize the face for writing the remainder of the line right from > extend_background instead of from background + extend_background. I don't see how this will help anything. To remind you: the display engine manipulates face IDs, it doesn't know anything about the faces themselves, and in particular cannot magically exchange a face's background color for some other color. > > Maybe I don't understand the question, because I see no problems > > here. Just coding. > > Maybe you're right. But I still don't see the light at the end of > this tunnel. I don't think I see the tunnel. I thought the issue was resolved when you posted your summary up-thread. What am I missing?