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.bugs Subject: bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages Date: Mon, 09 Dec 2019 14:59:20 +0200 Message-ID: <83sgltd593.fsf@gnu.org> References: <42c596c2-b5c1-9fc9-4b92-9c13b386d93d@yandex.ru> <83pnhgrlni.fsf@gnu.org> <83ftiasfdm.fsf@gnu.org> <83lfrulmva.fsf@gnu.org> <76a012f5-8cdd-75d5-322e-a453a612c655@yandex.ru> <83immxjs6q.fsf@gnu.org> <993b2f9c-6052-e791-3d3b-26d5fedd7d12@yandex.ru> <835ziuixke.fsf@gnu.org> <9c4768a5-ecce-68ce-c612-a001b2f6784d@yandex.ru> <8336dxh1ge.fsf@gnu.org> <6c68ceed-156c-a6f2-bf0f-21d7e9eb5692@yandex.ru> <831rthgy3u.fsf@gnu.org> <83o8wkfu63.fsf@gnu.org> <83r21gdnun.fsf@gnu.org> <839f1185-fc0c-0e8b-29fd-5431fb71ab2e@yandex.ru> <83o8wkdk3n.fsf@gnu.org> <45fcbf16-c9b4-ca15-7fa2-e7ea2137218c@yandex.ru> <83immreblb.fsf@gnu.org> <52b437d6-cbee-cea9-71c8-2a39311e602c@yandex.ru> <83a782es0a.fsf@gnu.org> <18e7e83d-9be8-c95f-d2b7-b2d8f00ef369@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="131649"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37774@debbugs.gnu.org, juri@linkov.net To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 09 14:00:20 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ieIeB-000Y1S-RH for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Dec 2019 14:00:19 +0100 Original-Received: from localhost ([::1]:39568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieIe5-0001Ia-Bt for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Dec 2019 08:00:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40633) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieIdw-0001Ha-7m for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 08:00:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieIdu-0000tb-OT for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 08:00:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46781) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieIdu-0000sF-KP for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 08:00:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ieIdu-0001C8-Fl for bug-gnu-emacs@gnu.org; Mon, 09 Dec 2019 08:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Dec 2019 13:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37774 X-GNU-PR-Package: emacs Original-Received: via spool by 37774-submit@debbugs.gnu.org id=B37774.15758963854518 (code B ref 37774); Mon, 09 Dec 2019 13:00:02 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 9 Dec 2019 12:59:45 +0000 Original-Received: from localhost ([127.0.0.1]:52754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieIdc-0001Al-Np for submit@debbugs.gnu.org; Mon, 09 Dec 2019 07:59:45 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieIdb-0001AS-6H for 37774@debbugs.gnu.org; Mon, 09 Dec 2019 07:59:43 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ieIdV-0000Xc-J4; Mon, 09 Dec 2019 07:59:37 -0500 Original-Received: from [176.228.60.248] (port=4367 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ieIdV-0003e7-0i; Mon, 09 Dec 2019 07:59:37 -0500 In-reply-to: <18e7e83d-9be8-c95f-d2b7-b2d8f00ef369@yandex.ru> (message from Dmitry Gutov on Sun, 8 Dec 2019 23:20:52 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:173102 Archived-At: > Cc: 37774@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Sun, 8 Dec 2019 23:20:52 +0200 > > > OK, I've now reviewed all the callers of face-spec-recalc, and all of > > its callers' callers, and wrote a bunch of tests to make sure that we > > don't break anything (or at least anything important). > > Thank you. That's pretty comprehensive. I would suggest to install those > tests Done. > but I wonder how they would interact with a long-running test > session. Not sure I understand: each test runs in a separate session. What am I missing? > Running them in an interactive session was tricky as well because > visiting any file, even in 'emacs -Q', automatically leads to > diff-mode.el being loaded, and so (should-not (featurep 'diff-mode)) > fails right away. I guess you loaded the tests as a .el file? They are normally loaded as .elc, which doesn't load diff-mode, and load-theme doesn't activate diff-mode either. In any case, the tests as committed all pass for me, including interactively. But it would be safer to replace the faces with ediff-* faces, I agree. > They also rely on the existing themes, the definitions of which will change. I wanted to avoid creating dummy themes just for this test, but if you'd like to do that, feel free. > > The tests in > > the patch below all pass for the current code on master, and include a > > couple of comments where the changes to implicitly inherit :extend by > > themes are supposed to change the expected result. If after applying > > your patch all the tests still pass, both in -batch and in an > > interactive session, then I think we are good to go (after adding the > > necessary documentation and NEWS entry). > > They do! If by "still pass" you mean the version of these tests where > the expected values are replaced with the values from "should be" comments. Yes. > All right, how does the attached patch look? Looks good, see below. > In addition to it, I'd like to revert the part of 64687872f6 that > changed the bundled themed (etc/themes/*). Is that okay? Fine with me, but if you do that, you will _have_ to add a special theme, or else we won't be able to test some of the features, because no theme will set the :extend attribute. > diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi > index fa81b2e953..df6f07496e 100644 > --- a/doc/lispref/display.texi > +++ b/doc/lispref/display.texi > @@ -2499,9 +2499,9 @@ Face Attributes > @code{nil} to not use this face for the space between the end of the > line and the edge of the window. When Emacs merges several faces for > displaying the empty space beyond end of line, only those faces with > -@code{:extend} non-@code{nil} will be merged. By default, only > -@code{region} and @code{hl-line} faces have this attribute set to > -@code{t}. > +@code{:extend} non-@code{nil} will be merged. This attribute is > +different from the others in that when a theme doesn't define it for a > +face, the value from the default spec is inherited. Why did you lose the sentence that starts with "By default"? > +This attribute behaves specially when theme definitions are applied: > +if the theme doesn't specify its value for a face, the value from the > +default spec is used. "Its value" is ambiguous, suggest to say "an explicit value" instead. Also, "default spec" is somewhat unclear. I would suggest "original face definition by @code{defface}" and add a cross-reference to "Defining Faces", where defface is described. > Consequently, themes usually shouldn't touch > +this attribute at all. I don't think we should say that, it sounds like a guideline, which it isn't. We should either remove it, or make it just something to consider, by saying "...shouldn't set this attribute, unless the theme has a good reason to do so." > - ;; defface spec entirely (rather than inheriting from it). If > - ;; there was no spec applicable to FRAME, apply the defface spec > - ;; as well as any applicable X resources. > + ;; defface spec entirely rather than inheriting from it, with the > + ;; exception of the :extend attribute (which is inherited). Please keep the original wording by including "rather than inheriting from it" in parentheses. Thanks.