From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face Date: Tue, 29 Dec 2020 16:53:07 +0200 Message-ID: <83eej8k6jw.fsf@gnu.org> References: <<<<<>>>>> <<<<<<87eejc9pnm.fsf@gnus.org>>>>>> <<<<<>>>>> <<<<<<5e99c39b-b67b-4184-a890-2cae38fb40de@default>>>>>> <<<<<<87a6tzk5iv.fsf@metalevel.at>>>>>> <<<<<<83h7o7kufk.fsf@gnu.org>>>>>> <<<<<975c150b-99aa-4143-b057-8b5ec7caec19@default>>>>> <<<<<838s9jkqh7.fsf@gnu.org>>>>> <<<>>> <<<<835z4mkpvz.fsf@gnu.org>>>> <<<5dfff982-e496-46fe-9efd-1e0edd4f0be8@default>>> <<<83o8idkehc.fsf@gnu.org>>> <<<83mtxxkcwk.fsf@gnu.org>>> <<9a600718-7caf-4ad0-a664-0ebafba63e57@default>> <<83im8lk9lp.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21299"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, 45428@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 29 15:54:10 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kuGO1-0005Rd-Tn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 15:54:10 +0100 Original-Received: from localhost ([::1]:52952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuGO0-0003Xq-P6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 09:54:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51836) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuGNu-0003Xj-GF for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 09:54:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54787) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuGNu-0006VC-9d for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 09:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuGNu-0005rV-66 for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 09:54: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, 29 Dec 2020 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45428 X-GNU-PR-Package: emacs Original-Received: via spool by 45428-submit@debbugs.gnu.org id=B45428.160925360822489 (code B ref 45428); Tue, 29 Dec 2020 14:54:02 +0000 Original-Received: (at 45428) by debbugs.gnu.org; 29 Dec 2020 14:53:28 +0000 Original-Received: from localhost ([127.0.0.1]:38100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuGNL-0005qf-HE for submit@debbugs.gnu.org; Tue, 29 Dec 2020 09:53:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuGNH-0005qS-Gr for 45428@debbugs.gnu.org; Tue, 29 Dec 2020 09:53:26 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59938) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuGNA-0006HV-OL; Tue, 29 Dec 2020 09:53:16 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2761 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kuGN9-00036k-01; Tue, 29 Dec 2020 09:53:15 -0500 In-Reply-To: (message from Drew Adams on Mon, 28 Dec 2020 12:44:11 -0800 (PST)) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:196934 Archived-At: > Date: Mon, 28 Dec 2020 12:44:11 -0800 (PST) > From: Drew Adams > Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, > 45428@debbugs.gnu.org > > > > I wouldn't think of this as a doc bug because (1) > > > this behavior is so unusual > > > > Which behavior are you alluding to here? and what is the "doc bug", > > exactly? > > I was alluding to the fact that the doc says that > "Remaining arguments form a sequence of PROPERTY > VALUE pairs", but the inserted text seems to show > the effect of the pair `face (:height 10.0)', even > though that pair isn't present. You are still not saying where did you find the documentation which says that. I will go ahead and guess that you mean the doc string of 'propertize', which says: First argument is the string to copy. Remaining arguments form a sequence of PROPERTY VALUE pairs for text properties to add to the result. If that is the documentation you are complaining about, then I find nothing wrong with, because the original recipe, viz.: (propertize "hello" 'face (quote (quote '(:height 10.0)))) does indeed call 'propertize' with a pair, as documented: the PROPERTY is 'face and the VALUE is (quote (quote '(:height 10.0))). So the doc string describes this use case accurately, and there's nothing wrong with the _form_ of the PROPERTIES arguments to 'propertize' in this case. The original bug report said something different: > In 39.12 Faces, the Emacs Lisp documentation states: > > One way to represent a face is as a property list of attributes, > like ‘(:foreground "red" :weight bold)’. Such a list is called an > “anonymous face”. [...] > $ emacs -Q --eval '(font-lock-mode 0)' \ > --eval "(insert (propertize \ > \"hello\" \ > 'face (quote (quote '(:height 10.0)))))" > > In this case, the anonymous face is not specified as a property list, > but as a symbolic expression of the form (quote (quote (quote ...))), > and still works. Is this the intended result, and can we rely on it? If > so, could you please document it? This complaint is about a different instance of "pairs": it's about the form of the _value_ of the 'face' property, not about the form of the "&rest PROPERTIES" arguments of 'propertize'. However, that original complaint is incorrectly assuming that a face can _only_ have the form of an anonymous face, which is a property list of attribute/value pairs. The text it quotes from section 39.12 of the ELisp manual is incomplete; here it is in its entirety: One way to represent a face is as a property list of attributes, like ‘(:foreground "red" :weight bold)’. Such a list is called an "anonymous face". For example, you can assign an anonymous face as the value of the ‘face’ text property, and Emacs will display the underlying text with the specified attributes. *Note Special Properties::. If you follow the cross-reference to "Special Properties", you will find that the value of the 'face' property can be one of the following: . a face symbol . a property list of attribute/value pairs . a cons cell of the form (foreground-color . COLOR) . a cons cell of the form (background-color . COLOR) . a list of faces, each one given by any of the above forms . a cons cell of the form (:filtered FILTER FACE-SPEC), where FACE-SPEC is one of the above forms And now you should recognize that the strange format of the property value, which prompted the original bug report, fits the "list of faces" format as described by the 5th item in the above list. So I still don't see a problem with the documentation in this case. I think the only problem/surprise here could be that Emacs acted according to a single valid part of the face spec and seemingly silently ignored the invalid ones, logging an error message in *Messages* instead of perhaps rejecting it wholesale, and the OP failed to look in *Messages*. However, that doesn't seem to be a bug: the face spec is invalid, and so invokes undefined behavior, where we only have an obligation not to crash nor lock up Emacs (which is why the error message isn't displayed as such: the face merging happens at display time, and we cannot usefully signal an error from redisplay). > Having heard the misunderstanding that we've made > (still without my understanding, so far), do you > have a suggestion for how to dispel/prevent it? Tell users to read the docs? But we already know that doesn't really work...