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, 28 Aug 2019 12:07:24 +0300 Message-ID: <83lfvdd5f7.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186029"; 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 28 11:07:28 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 1i2tvM-000mGL-CB for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 11:07:28 +0200 Original-Received: from localhost ([::1]:33794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2tvK-0007kS-Ti for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 05:07:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37757) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i2tvE-0007k8-LY for emacs-devel@gnu.org; Wed, 28 Aug 2019 05:07:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i2tvE-0000z7-Bp; Wed, 28 Aug 2019 05:07:20 -0400 Original-Received: from [176.228.60.248] (port=2973 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i2tvD-0006YU-It; Wed, 28 Aug 2019 05:07:20 -0400 In-reply-to: <3ea328a6-2b35-5a01-77a1-bbf9ff7f16f2@gmx.at> (message from martin rudalics on Wed, 28 Aug 2019 10:35:11 +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:239640 Archived-At: > Cc: emacs-devel@gnu.org > From: martin rudalics > Date: Wed, 28 Aug 2019 10:35:11 +0200 > > > When in 3 it says "remove", what does it means? set it to x, to default or > > to nil? > > > > In case we don't extend, the extra space we add after the line should > > have the default, face or the last in the line?? > > The term "remove" was meant wrt the current face used by the iterator. > If, for example, the current face of the iterator is the one specified > by the region face, then it probably specifies some background used > for "normal" text. When the display engine arrives at the newline > character it checks whether the current face has the extend_background > bit set and either reuses an existing or realizes a new face based on > the background of the current face and that bit. 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. > What realizing has to do when extend_background is false is not > entirely clear to me either. Suppose we have a newline character that > is contained both in the region and a multiline comment and the region > face results in an extend_background false bit while the comment face > results in an extend_background true bit for the corresponding > realized faces. > > Conceptually, this means that the spaces at the end of the line should > have the comment background but unless we expand the extend_background > bits into full pointers to other realized faces (and have face merging > set up these pointers and the display engine resolve them) I see no > way how this could be realized. So the rest of the line would be > shown with the default face's background instead (or do whatever we do > now when we don't expand) which obviously won't look good. I don't see a problem here. A user who doesn't want the region face's background extend to the end of line wants only text (as opposed to whitespace after the newline) to have the region's background, and that's true both to regions that cross line boundaries and regions that end at a newline. > Maybe the display engine could consult, with the stop position > privilege triggered by the newline character in mind, whether the > extend_background false setting of the current face could result in > applying another, lower-priority face specified by font-locking and > consult the extend_background bit of the corresponding realized face. I don't think I understand this proposal.