From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#37774: 27.0.50; new :extend attribute broke visuals of all themes and other packages Date: Sat, 7 Dec 2019 20:55:31 +0200 Message-ID: <839f1185-fc0c-0e8b-29fd-5431fb71ab2e@yandex.ru> References: <87o8xwrjba.fsf@bernoul.li> <834kzooo8e.fsf@gnu.org> <877e4d7yzf.fsf@bernoul.li> <83imnvg53q.fsf@gnu.org> <87zhh2ofc9.fsf@bernoul.li> <87k186nsku.fsf@bernoul.li> <87imna18nc.fsf@mail.linkov.net> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="269083"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: 37774@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 08 04:47:54 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 1idnY1-0017rA-So for geb-bug-gnu-emacs@m.gmane.org; Sun, 08 Dec 2019 04:47:54 +0100 Original-Received: from localhost ([::1]:55430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idnY0-00027H-6h for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Dec 2019 22:47:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57970) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idnXS-00025q-TF for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:47:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idnXK-0007lK-1U for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:47:13 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44302) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1idnXB-0007iK-P9 for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1idnXB-0005M6-Nw for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2019 22:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Dec 2019 03:47:01 +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.157577677820523 (code B ref 37774); Sun, 08 Dec 2019 03:47:01 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 8 Dec 2019 03:46:18 +0000 Original-Received: from localhost ([127.0.0.1]:50270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1idnWT-0005Kw-Fx for submit@debbugs.gnu.org; Sat, 07 Dec 2019 22:46:17 -0500 Original-Received: from mail-wm1-f42.google.com ([209.85.128.42]:33227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1idnWQ-0005Kf-Fg for 37774@debbugs.gnu.org; Sat, 07 Dec 2019 22:46:15 -0500 Original-Received: by mail-wm1-f42.google.com with SMTP id y23so12719417wma.0 for <37774@debbugs.gnu.org>; Sat, 07 Dec 2019 19:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TiwJ/W5HvCoENXiJQ65cO2xM1K4ZnCIFmIbH5b1pLSI=; b=s1bXV6+FIsCKjnWoQD2je8i8DM8Fp4crriwL/WrcPSVuLoETbd7gM11g+pOltgb+Zg pvgm9wMMt4trPRhzNbeCiFdKS48G327cT2+Urc6hg5hgBRjPT1SKZ/COvP3Ktjwwrlg1 RFd4l6ryThDecAAs9o0DcHcn3GRumlpjagkEoaFF3n6r9EJU+k9EP8p5tgbxX/lxvV+Z IfXjgQAsgNjbR7VuxC7V0lu8S8wXHePWQn7lwWJxxRUWxvroCvLGl39LS5Bm7bke7XNL r0FtV8vrPuFD9SVPiAV0v5xubj6SN8roV0YgnatijIUfoBxKZkVw5sDppiGUkexYSeKK x99g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TiwJ/W5HvCoENXiJQ65cO2xM1K4ZnCIFmIbH5b1pLSI=; b=uJ0YRZ/QlwPugyar58eku9ftqNpYNUATOOQRO/1WCh/vQRp+PxtuhfLMiZwToZT1dQ P4c45LGAmU32gxsaF+R/BkDqYZfDC1iNtaUbbqdYEtwhiuglyCqpavva9jaAea8lLylv ElWrA9XktQkXuv3Vj5nfVvxZWJHdv9WXnBr51n3T5Oxy4ptFYeIPJ85MSOjz/awwg1hw K4oEM0D0BuWU3ZGzQCFnrbMF8t0U/eChabiKVEFMKP5RqKiFFT6wTGy4TSmJHNxrq9+q q4yqYeBhnkBWt1QsZurx928MbE0YLxPnrYkBaYprT7pg7LfoaJ0Mbnu+HuHCH/Ok22cG arJg== X-Gm-Message-State: APjAAAWBFpZZ7u6Uez5RTodgDUYHm1m63NGN31oJ5xi5AD2wSdoRPSxg GiCKhPVdGrz84P/ryrPqpGN4W9FF X-Google-Smtp-Source: APXvYqwHTp5LTJs3f7ln3iCu1XeMwd0RtW+ClWSM4+kul2S7AHPqDUKoldtQnhgBk94Ab1lV/EGegw== X-Received: by 2002:a05:600c:10cd:: with SMTP id l13mr17597684wmd.102.1575744939698; Sat, 07 Dec 2019 10:55:39 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id p10sm7425946wmi.15.2019.12.07.10.55.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Dec 2019 10:55:38 -0800 (PST) In-Reply-To: <83r21gdnun.fsf@gnu.org> Content-Language: en-US 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:173023 Archived-At: On 07.12.2019 19:53, Eli Zaretskii wrote: >> Cc: 37774@debbugs.gnu.org, juri@linkov.net >> From: Dmitry Gutov >> Date: Sat, 7 Dec 2019 19:06:08 +0200 >> >>> I meant to avoid such consequences by making sure those other callers >>> can never trigger this new processing of :extend. >> >> Eli, what you're asking for would be actively harmful. >> >> To make an analogy, when we're changing a core Emacs behavior, we >> shouldn't try to make it work only on Tuesdays. Even if the original bug >> reporter observed the problem on a Tuesday. > > Sorry, I don't see the analogy. > > We are not trying to change the core behavior, we are trying to change > how themes define faces, in a way that makes the :extend attribute be > implicitly inherited from the default spec of the face to the face > after theme's customizations. We're really trying to change how a face's attributes are calculated based on its default spec, as well as enabled themes. There are different callers to face-spec-recalc because different user features require that re-calculation. > All I want is to make sure no other > caller of face-spec-recalc, one that has nothing to do with themes > defining faces, picks up the change, because that would be unintended. > If you consider this incorrect or unjustified, please explain why. Here's some examples: enable-theme needs that recalculation because a different set of themes is now in effect, and face attributes need to be updated. face-set-after-frame-default needs that because a frame's parameters can affect how faces look as well. frame-set-background-mode needs that to update how face specs are interpreted given the changed background mode. All of these affect how a face spec is evaluated, which affects how theme specs and user specs apply to the face. Which should be able to change which spec the value of :extend is taken from. Or, to look at it from another direction: if we create a special different version of face-spec-recalc purely for custom-theme-set-faces, and face-set-after-frame-default wouldn't use it, whatever changed logic we implement wouldn't apply to new frames. >> Can we please focus on the more pressing question: whether the proposed >> patch actually works, and does that reliably, or are there >> scenarios/configurations where it would do something unexpected. > > We were considering only one scenario: that of a theme defining its > own face specs. Right. But this scenario has different configurations. Like a themed spec can inherit from some other face (and the first face's default has ':extend t' as well). I was wondering what's going to happen if the user customizes that other face to have ':extend t' or ':extend nil'. But my testing shows it behaves as expected. > face-spec-recalc is called in other scenarios, but I > don't think we should consider them, because we don't want to change > the behavior in any of those other scenarios. I'm pretty sure they'll be fine. Or if not, it'll likely be a bug somewhere else. >> + (when (and theme-face-applied >> + (eq 'unspecified (face-attribute face :extend frame t))) >> + (let ((tail (plist-member default-attrs :extend))) >> + (and tail (face-spec-set-2 face frame >> + (list :extend (cadr tail)))))) > > This is OK, but why say > > (list :extend (cadr tail)) > > instead of just > > tail > > ? Unless I'm missing something here, the value of 'tail' here should > be (:extend VAL), where VAL is either t or nil. Right? I'm not sure :extend is always the last pair in the list. ELISP> (plist-member '(:a 1 :b 2 :c 3) :b) (:b 2 :c 3) I could use map-elt, though. If it's allowed in faces.el.