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: Tue, 03 Dec 2019 18:21:33 +0200 Message-ID: <83immxjs6q.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77191"; 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 Tue Dec 03 18:06:41 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 1icBdJ-000Jwn-AH for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 18:06:41 +0100 Original-Received: from localhost ([::1]:56274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icBdH-00019N-7K for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 12:06:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33843) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icAwE-0008JO-1V for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:22:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icAw8-00030E-9g for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:22:06 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34985) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icAw6-0002yg-9r for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:22:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icAw6-00085q-5B for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:22: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: Tue, 03 Dec 2019 16:22: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.157539011831100 (code B ref 37774); Tue, 03 Dec 2019 16:22:02 +0000 Original-Received: (at 37774) by debbugs.gnu.org; 3 Dec 2019 16:21:58 +0000 Original-Received: from localhost ([127.0.0.1]:40958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icAw2-00085Y-2R for submit@debbugs.gnu.org; Tue, 03 Dec 2019 11:21:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icAw0-00085J-Ad for 37774@debbugs.gnu.org; Tue, 03 Dec 2019 11:21:56 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1icAvp-0002Wj-QJ; Tue, 03 Dec 2019 11:21:46 -0500 Original-Received: from [176.228.60.248] (port=4229 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1icAvn-0005eK-Df; Tue, 03 Dec 2019 11:21:45 -0500 In-reply-to: <76a012f5-8cdd-75d5-322e-a453a612c655@yandex.ru> (message from Dmitry Gutov on Tue, 3 Dec 2019 02:01:10 +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:172816 Archived-At: > Cc: 37774@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Tue, 3 Dec 2019 02:01:10 +0200 > > > 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? It's the main idea behind the feature. Without it, the feature makes no sense at all. > 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. > > 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. > > 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: get_lface_attributes merge_face_vectors merge_named_face merge_face_ref internal-make-lisp-face internal-set-lisp-face-attribute The last two should make it clear how defface makes a face with all of the attributes. > 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. 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.