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: Tue, 3 Dec 2019 02:01:10 +0200 Message-ID: <76a012f5-8cdd-75d5-322e-a453a612c655@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> 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="79302"; 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 Tue Dec 03 01:02:42 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 1ibveM-000KTR-AA for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 01:02:42 +0100 Original-Received: from localhost ([::1]:45940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibveK-0004FH-Dd for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Dec 2019 19:02:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40552) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibvdz-0004Aw-6N for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 19:02:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ibvdv-00005e-Ia for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 19:02:18 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ibvdi-0008Sy-8H for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 19:02:08 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ibvdi-0005qc-3n for bug-gnu-emacs@gnu.org; Mon, 02 Dec 2019 19:02: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: Tue, 03 Dec 2019 00:02: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.157533128422414 (code B ref 37774); Tue, 03 Dec 2019 00:02:02 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 3 Dec 2019 00:01:24 +0000 Original-Received: from localhost ([127.0.0.1]:39139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibvd6-0005pR-8W for submit@debbugs.gnu.org; Mon, 02 Dec 2019 19:01:24 -0500 Original-Received: from mail-wm1-f44.google.com ([209.85.128.44]:52738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ibvd4-0005p5-42 for 37774@debbugs.gnu.org; Mon, 02 Dec 2019 19:01:22 -0500 Original-Received: by mail-wm1-f44.google.com with SMTP id p9so1159640wmc.2 for <37774@debbugs.gnu.org>; Mon, 02 Dec 2019 16:01:22 -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=cHrD1yXqrK33Ll4O5ncxr4rPiFUW+nDDgi63BCRTRQI=; b=fSh2/WsIPKn+7YVswXWpn2AFUmQLydxZmXR+Ih1niWSQ3I8Okgul4VigXUOqK2tXn5 wHaSYKD1tOLox9yWjvfmEoIeitH299leyI+PWE9txA+dkC72rnM7Z7BQKAVsxpIY87aj Op7rtjCXwo+QmovUESq5wHltpmZNcxwA9jMKvgP57Qq0iTUkMTpPzdWGvdfJyqg2ZbzA viXuxQvD+wx7q7YFt8e+e9ZIDA326i/Wc27ugkbiRQy8UEAtMJwUIT+t4q8iTMnZaTF3 /R2aNvqmdg5XFHZUaR64YcPJZYTKx7JGro9Onk03pQ2GXB0aAH1Ag9+7tRYSb/T6gYe3 RLTQ== 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=cHrD1yXqrK33Ll4O5ncxr4rPiFUW+nDDgi63BCRTRQI=; b=TLBEtyw0Ls4W/H/sUUfezGY3bha4Vd67A2olaJFC1misz/HeQkQI6R0g+RXf8GyH6k WeY0qQAgX5SFMQSyxm19JfQssUB7z07ytpfzuV/Wdlt6QhDYJkUIH2Yal1k7jWb+3GNP JLnhhxHxRYxdUq/RAQZtjPby8yQkdISuDdUB3u1pnIGtZSkWvy+MOBswy9SoOMF/gV4E 50r3IIYY/00N9q21RszXAmXfjSkGPpLtmlkEeP+U7i8GyBaUfUz8b6XLKt6DgDVZBb+Z 6+5BWu6DuT79epL1kyldYZAmXtdgDcS1fjsv+Ysfd7zWUOBRfLEMr2AAsAtQcfckiljC FvAw== X-Gm-Message-State: APjAAAV45NHiFpBDqimw2RbuL6Qv7xdVdGMDHJKVtTDNg/x4fB6OO4+F pFcLAMBLuK7iZwQ1y6yoNxLIXB6d X-Google-Smtp-Source: APXvYqz8PfDKCwUpD3wwwSP9gEc4QHhctzhTJkIICUhkAKCbH0ZMZbgq5b9nrLngIFxzRgoP1PJ1bw== X-Received: by 2002:a1c:40c1:: with SMTP id n184mr33206843wma.116.1575331275932; Mon, 02 Dec 2019 16:01:15 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id a206sm1104703wmf.15.2019.12.02.16.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 16:01:14 -0800 (PST) In-Reply-To: <83lfrulmva.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:172794 Archived-At: On 02.12.2019 18:21, Eli Zaretskii wrote: >> Cc: 37774@debbugs.gnu.org, juri@linkov.net >> From: Dmitry Gutov >> Date: Mon, 2 Dec 2019 02:05:10 +0200 >> >> feel free to change its :extend attribute. >> >> OK, done. But it feels pretty useless, considering any theme where this would affect something would have to repeat the 'extend t' definition anyway. > > That's true for themes, but what about face customization by users > using the likes of set-face-background? For them, we should have the > attribute even when the default face definition is empty. Fair enough. > As for the other aspect of this: the idea was that almost all faces do > not need to be extended, something that no default will succeed to do > silently. Whose idea was it? 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. >> Basically, on the C level each Lisp face is represented by an array of >> its attributes, where each array element holds the value of the >> corresponding attribute. Once this array is computed, we can (and do) >> manipulate just the array, and for all practical purposes can forget >> about the face's symbol. Using a symbol property would then need to >> keep the symbol around at all times, which is inconvenient and would >> make the code ugly. >> >> I don't think so. Once the symbol is gone, whatever left is just the value. So when this array is computed, the function doing that would merge the faces attributes with whatever attributes are specified using the alternative symbol property. > > 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 (*). I'm talking about merging the attributes from the two properties (old and new) when computing the value of the array. TBH, this is difficult to discuss. "Merging" and "array computation" are very generic terms. (*) We shouldn't be talking about face merging at all because whatever happens after an "array" has been "computed" is opaque to defface, custom-theme-set-faces and custom-set-faces. So we should only discuss how "array" is computed, and what affects its resulting value, and not whatever happens next. >> To be more exact, the current face attributes are also assigned to a symbol property (face-defface-spec). We can add another property: face-default-spec, which would contain attributes that should apply to the face unless explicitly overridden in face-defface-spec. It could even be set by a new defface keyword instead of plain 'put', but that's a minor concern IMO. (Option two ends here). >> >> This seems to be the easiest way to go around the long-established behavior that custom-theme-set-faces overwrites the face attributes (instead of trying to merge them). We could do in the other way, but it would require changes in both custom-theme-set-faces and defface, as well as some other functions I imagine, and either a whitelist of attributes that would always be retained unless overridden. Or a wholesale change to retain all attributes by default. I might like the last option personally, but it would be a major breaking change. Still, all themes could be updated to account for it while keeping compatibility with older Emacs with little trouble (which is harder to do with the current :extend situation). > > 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 can only say that face-defface-spec and other > properties of face symbols are used by custom.el on the Lisp level, > whereas we were talking about what happens on the C level. On the C > level, face merging creates an unnamed face with its attributes > computed by the merging process, and that process currently takes the > :extend attribute into account. Any proposal to use face symbol's > properties instead will have to explain how those properties are > communicated to the merging process. Like I said, the new property I suggested is a way to go around having to change custom-theme-set-faces in an incompatible way. We would create a second "namespace" for face attributes that wouldn't be overwritten. >> But even if we'd overcome this annoyance, how do you specify this >> property for a face like below? >> >> '(:inherit foo :background "green" :underline "red") >> >> There's no symbol to put the property on. Do we say that such >> anonymous faces cannot support this attribute? Unclean. >> >> See above. Just add ':extend t' (or nil) to the end of the value. > > So you propose to have both symbol property _and_ a face attribute? Yes. Sorry for not making this clear. Since you outlined the "unnamed face value" situation, I've had to amend the idea a little (**). Further, since the :extend attribute would still be used, this wouldn't require too many changes on the C level. The new symbol property could be used for different attributes, but it seems like :extend needs it the most. (**) Although we could go back to my previous suggestion of only setting "extend" via symbol property. That would still require the new :extend attribute, but it could remain hidden from the user and the Lisp code.