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: Thu, 5 Dec 2019 03:44:22 +0200 Message-ID: <993b2f9c-6052-e791-3d3b-26d5fedd7d12@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> 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="269621"; 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 Thu Dec 05 02:45:58 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 1icgDN-0017tg-NX for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 02:45:57 +0100 Original-Received: from localhost ([::1]:48820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icgDM-0001B3-2E for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Dec 2019 20:45:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54816) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icgCc-000177-Ug for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 20:45:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icgCa-0005Q6-K0 for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 20:45:10 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36876) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icgCX-0005LD-V8 for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 20:45:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icgCU-0005uC-Ir for bug-gnu-emacs@gnu.org; Wed, 04 Dec 2019 20:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2019 01:45: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.157551028822650 (code B ref 37774); Thu, 05 Dec 2019 01:45:02 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 5 Dec 2019 01:44:48 +0000 Original-Received: from localhost ([127.0.0.1]:42849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icgCF-0005tF-M0 for submit@debbugs.gnu.org; Wed, 04 Dec 2019 20:44:48 -0500 Original-Received: from mail-wr1-f54.google.com ([209.85.221.54]:41014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icgCD-0005sx-KZ for 37774@debbugs.gnu.org; Wed, 04 Dec 2019 20:44:46 -0500 Original-Received: by mail-wr1-f54.google.com with SMTP id c9so1495773wrw.8 for <37774@debbugs.gnu.org>; Wed, 04 Dec 2019 17:44:45 -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=i3W4gCcPH64QHZ55LsDm1bcHfVtb1yI06xZqGO/89HQ=; b=lM0qe1ocyfPoPF008F2amXzfSSzgFXPju2FcCUpvmKf2vm8dq3hvUU9brgfixkrDpE HixjW2thCaSR+W9aqVo625K4sufOQY2KUZWFpDJsV89ESBYDnx3GEm00BW4bBnL+JjAN PJcp1++fhDEkwvuX/dN9YeKXHOKDETq2Ir43t+B7qG12+ezXrc4LP2gtezzmQ7o6MHHG 6Gm/AskwVzsTbvphaqCCmPxEvKGBCO86C9G6BQ3WzyoDpJMS8IWzMvqdEoGB8P47uwBT y0JbRpZVlt6oMNsKYgRhkASwyiumYoVBY9cAQrQriwFiz4MAIVAvDZVC27gwa8aTzg+H GFjw== 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=i3W4gCcPH64QHZ55LsDm1bcHfVtb1yI06xZqGO/89HQ=; b=kH3+pOLGG0WssAmq7lXlbvLHaU9aXXabxyvm/FLsip78rEJyr6pvjZumASnkaQkDpw D+JRir/KDHNuenG0nI9dNj56IpbVNo+TUAH/+UAK/UorbFhXEgaDr3v6/86u3OAx30+p VEG7WaPx1e/uyhjkiqGz93TmfSHjesxKDQeyi5dJMvf+e8kD0CdUy+jdiLBMeFTi7xyr n1b9t3ctQxPef3pGmAYiZO5+K3VXVif+MXUYUcQS4lHlBxeXchhBkMxDvL8DttgqjIvv 1qOufYR/ewIuTwxuJuSYNvD3VOQt+wFVbLYi3KthZt+JlKKPBPPFtw0Iy0FKYfnIAS8x F5ww== X-Gm-Message-State: APjAAAUORgN9fP0bFWUX9EfJZOz5dBcrM3Ns/Aoq9qzaBKDJkHbMUjwc baJkOclhSRW4vabMlUtcIwE= X-Google-Smtp-Source: APXvYqxtojEcAEu9MrEFujxCkz8bbv4LuwMvi1CFytv6JH5dfs7XbedCjG6GTW/U6BdNUQVo+lF8zg== X-Received: by 2002:adf:d848:: with SMTP id k8mr6863136wrl.328.1575510264638; Wed, 04 Dec 2019 17:44:24 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id b17sm10157290wrp.49.2019.12.04.17.44.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2019 17:44:23 -0800 (PST) In-Reply-To: <83immxjs6q.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:172865 Archived-At: On 03.12.2019 18:21, Eli Zaretskii wrote: >> I think we can all agree about not extending foreground and related >> attributes, but extending background is a long-standing behavior. So it >> would make sense to introduce non-extending backgrounds only in select >> faces and gradually. I think that's the general expectation in the Emacs >> community. But we don't have to do this, we can go another way. > > I don't think we should restart this discussion, we already had it. Fair enough. >>> The array is computed only once, whereas merging happens many times >>> and in different places. So we cannot compute the value of an >>> attribute only once, because its value depends on what other faces are >>> being merged, on whether their :extend attribute is set. and on >>> whether the particular merging process cares about :extend. >> >> I'm not talking about face merging (*). > > This whole issue, and in fact the feature itself, is about face > merging, and only about it. Emacs displays faces by merging > attributes from all of the possible sources of face information that > are in effect at a given buffer position. If the effect of the new symbol property is recorded in the array, whatever calculations happen thereafter using different arrays that represent faces (named or otherwise) should be orthogonal to my proposal. >>> I don't think I understand your proposal in concrete terms, and you >>> didn't read the code to check your proposal against the actual >>> implementation, so this is a sure way to misunderstandings and talking >>> past each other. >> >> You haven't pointed at any code to read. So if this email doesn't help >> reach clarity, could you give some pointers? > > I suggest to start with the large comment at the beginning of > xfaces.c, and then proceed to read these functions: Thank you. > get_lface_attributes So apparently lface_from_face_name_no_resolve is the place where a face name turns into an plist-like array of attributes. So we could, as a rough idea, look up the symbol property there and, if present, merge its contents with the return value. I'm not quite sure of the purpose behind Vface_new_frame_defaults (vs. just using props on face symbols), but we could add a similar storage for "transient face spec". And in the frame structs too. > merge_face_vectors > merge_named_face > merge_face_ref > internal-make-lisp-face > internal-set-lisp-face-attribute The last function might grow a new optional attribute: TRANSIENTP, if we want to be able to change such "transient" attributes at runtime. To define "transient" here: these will be attributes that are not affected by custom-theme-set-faces unless explicitly mentioned in the corresponding specs. Which is what we had been discussing for :extend for quite a while. >> The new symbol property could be used for different attributes, but it >> seems like :extend needs it the most. > > Sorry, still not clear. Maybe providing examples of defining a face > to be extended, and then repeating the above in more detail with > references to the examples, would help in clearing the picture. The new definition for diff-added would look like: (defface diff-added '((default :inherit diff-changed) (((class color) (min-colors 257) (background light)) :background "#eeffee") (((class color) (min-colors 88) (background light)) :background "#ddffdd") (((class color) (min-colors 88) (background dark)) :background "#335533") (((class color)) :foreground "green")) "`diff-mode' face used to highlight added lines.") (put 'diff-added 'face-transient-spec '((t :extend t))) Or maybe like: (defface diff-added '((default :inherit diff-changed) (((class color) (min-colors 257) (background light)) :background "#eeffee") (((class color) (min-colors 88) (background light)) :background "#ddffdd") (((class color) (min-colors 88) (background dark)) :background "#335533") (((class color)) :foreground "green")) "`diff-mode' face used to highlight added lines." :transient '((t :extend t)))