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: Sat, 31 Aug 2019 10:57:40 +0300 Message-ID: <83zhjp937v.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> <83mufr9gya.fsf@gnu.org> <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="95590"; 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 Sat Aug 31 09:57: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 1i3yGi-000OWs-QY for ged-emacs-devel@m.gmane.org; Sat, 31 Aug 2019 09:57:56 +0200 Original-Received: from localhost ([::1]:43026 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3yGh-0000fE-Ht for ged-emacs-devel@m.gmane.org; Sat, 31 Aug 2019 03:57:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39423) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3yGZ-0000ct-B0 for emacs-devel@gnu.org; Sat, 31 Aug 2019 03:57:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i3yGZ-0000kg-0o; Sat, 31 Aug 2019 03:57:47 -0400 Original-Received: from [176.228.60.248] (port=1291 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i3yGY-00051D-0u; Sat, 31 Aug 2019 03:57:46 -0400 In-reply-to: <03a80221-5222-9b8b-86a1-67cef18df463@gmx.at> (message from martin rudalics on Sat, 31 Aug 2019 09:29: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:239719 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Sat, 31 Aug 2019 09:29:13 +0200 > > > I thought we already agreed that there's no other way of having this > > feature than to realize a face at each EOL. > > Then that's where we have been miscommunicating. The whole idea > behind the extend_background, extend_underline, ... bits was to avoid > the full handle_stop rigmarole at EOL, like finding the overlays and > text properties and processing them in the right order. We don't need everything from handle_stop, we only need the parts that affect the face. > The only missing step is to process the :extend attribute of any face > merged. For the normal background, this is the value of the > :background attribute of the last face that specified that attribute > and was merged in. For the extended background this is the value of > the :background attribute of the last face that specified that > attribute, had the :extend attribute set and was merged in. > > To put this into praxis, the face merger would maintain a shadow copy > of the background value. That shadow value would not get overwritten > when merging in the :background attribute of a face that does not have > the :extend attribute set. Eventually, we would wind up with two, > possibly distinct values of the background to realize - one for the > normal and the shadow value for the extended background. The face merger doesn't maintain any state, so I don't think this is easily done. > If we wanted to realize both faces - the one to use for the current > face and the one to use for extension - immediately (eagerly as I > coined it earlier), we could do that right after merging terminates. > We probably would set up a pointer to the realized face to use for > extension, so the iterator, when arriving at EOL, would find it right > away and make it current. That's all. > > But we probably don't want to realize the face to use for extension > immediately and do it - as we agreed earlier - lazily when the > iterator arrives at EOL. If lazy realization is hard to implement, there's nothing wrong with realizing both faces immediately, at each stop position. > Note: We could also try to find out whether there _is_ another stop > position before the next EOL after merging faces and, if there's none, > realize the extended face eagerly, but I'm not sure whether this idea > can be incorporated easily. Right. > > 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. > > But it knows where the background of a realized face is stored and > could easily realize a new face which is the same but for a different > background swapped in. Hardly rocket science for the display engine. If we extend faces to keep the information about how to do that, then yes, this can be done. > So what we could do is to simply maintain a vector of the values for > background, underline, etc. calculated at the last real stop position > and whenever the display engine encounters a newline, realize a face > with the values of that vector replacing the current values, use that > face for the spaces at the rest of the line, and restore the old face > for the normal text on the next line (unless we have several newlines > in a row and similar optimizations). That's possible, assuming faces are extended as mentioned above. But I'm not sure realizing both faces immediately ("eagerly") will not be an easier solution. > BTW: One problem with Ergus' proposal is that hacks like the one > proposed for Bug#15934 won't work any more. For that bug, we could > obviously set the :extend attribute of the respective highlight line > face but all instances in the wild using the same hack already would > be affected by our change. Yes, of course.