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 20:21:45 +0300 Message-ID: <83woexb3yu.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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="181975"; 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 19:22:35 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 1i31eV-000lBx-3i for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 19:22:35 +0200 Original-Received: from localhost ([::1]:39134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i31eU-0003CC-0I for ged-emacs-devel@m.gmane.org; Wed, 28 Aug 2019 13:22:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49450) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i31dn-0003AP-Ly for emacs-devel@gnu.org; Wed, 28 Aug 2019 13:21:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1i31dh-0008N0-Ne; Wed, 28 Aug 2019 13:21:47 -0400 Original-Received: from [176.228.60.248] (port=1803 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1i31dc-0003LS-TY; Wed, 28 Aug 2019 13:21:45 -0400 In-reply-to: (message from martin rudalics on Wed, 28 Aug 2019 14:19:03 +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:239645 Archived-At: > Cc: spacibba@aol.com, emacs-devel@gnu.org > From: martin rudalics > Date: Wed, 28 Aug 2019 14:19:03 +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. 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. > > 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. > > 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? > We could make :extend sticky in the sense that once an :extend for the > background has been defined, it will apply to all higher priority faces > as well. This would make specifying a nil :extend value idempotent to > not specifying a value at all as you (IIRC) proposed earlier. But the > mechanism then becomes considerably less powerful. I don't think this will be needed, or even desirable.