From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#45428: 27.1; (quote (quote (quote ...))) unexpectedly works as anonymous face Date: Tue, 29 Dec 2020 10:27:11 -0800 (PST) Message-ID: 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>> <83eej8k6jw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3272"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, stefan@marxist.se, triska@metalevel.at, 45428@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 29 19:28:25 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 1kuJjM-0000j2-Sf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 19:28:24 +0100 Original-Received: from localhost ([::1]:56226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuJjL-0006Tj-Th for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Dec 2020 13:28:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuJj0-0006Tc-84 for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 13:28:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56829) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuJj0-0005Cu-0x for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 13:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kuJiz-00055G-Tn for bug-gnu-emacs@gnu.org; Tue, 29 Dec 2020 13:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Dec 2020 18:28:01 +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.160926644419495 (code B ref 45428); Tue, 29 Dec 2020 18:28:01 +0000 Original-Received: (at 45428) by debbugs.gnu.org; 29 Dec 2020 18:27:24 +0000 Original-Received: from localhost ([127.0.0.1]:40142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuJiN-00054M-Gh for submit@debbugs.gnu.org; Tue, 29 Dec 2020 13:27:23 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:48820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kuJiL-000547-RZ for 45428@debbugs.gnu.org; Tue, 29 Dec 2020 13:27:22 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTI8l5F072211; Tue, 29 Dec 2020 18:27:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=YGe8tBzpLs9t+COYwZq3GoZB6HKd7hBiBvoOljjP0X4=; b=qeHhESwIch9ETV8SAlvrwn3T6xUbluQ0IC/+XS3o8ZM7zHZSx/fCm0Dfb9GdGQn/aeen 2AWe9m//G5RjhUQ4hCFWCT0AJ903+1dm5jE5GdBk0ZbHN2r82G1XFtbRkAtajUE5kGnh XIbx7J6Qphu+hu2TUczpFbuZO9UVC3+YoBA+czH9u6jVL4v9jZk42zIe2OiVC3YlZ9Nl sbVnT/ibE/wCrYSFf8cxd3wHiohjl6vae0JJIN/8LSJsRHvgk8Rts58mowLi9BVPwj+b d1d9pbD9a4bXN5fLs2YRLoiUwZWTRkZI+1ZzG9/owIC5dB6/KUrNw3IEjYF5uJ0ynfEs GQ== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 35ntpaq3k0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 Dec 2020 18:27:16 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BTIOvdl163264; Tue, 29 Dec 2020 18:27:15 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 35pf3x01dg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Dec 2020 18:27:15 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BTIRC3I008645; Tue, 29 Dec 2020 18:27:13 GMT In-Reply-To: <83eej8k6jw.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290117 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9849 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 mlxscore=0 mlxlogscore=999 clxscore=1015 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290116 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:196959 Archived-At: > The original bug report said something different:... > 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: >=20 > One way to represent a face is as a property list of attributes, like > =E2=80=98(:foreground "red" :weight bold)=E2=80=99. Such a list is cal= led an "anonymous > face". For example, you can assign an anonymous face as the value of > the =E2=80=98face=E2=80=99 text property, and Emacs will display the un= derlying text > with the specified attributes. *Note Special Properties::. I think it would help if that simple "See Special Properties" were called out explicitly as telling you to see that node for a complete description of the `face' property. The text before it and after it can indeed give a false impression about property `face' and how a face can be represented.=20 > 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: >=20 > . 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 >=20 > 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. Indeed. I thought that's what you might say. Yes, that description is fine. But I hope you'll recognize that the (quote (quote '(...))) example is a gotcha, especially given that the "Invalid face reference: quote" message is shown in *Messages* only after some action provokes redisplay, and it often is not seen in the echo area. Without your having piped up here to say "Please look in *Messages*" I wouldn't have noticed it, for example. If this were a court of law, your argument that the doc is fine would be convincing. But if we're trying to help and guide users, then I think this `quote' gotcha could be handled better. Better still perhaps, instead of trying to address the specific `quote' gotcha (which is particularly misleading), the "Invalid face..." interaction could perhaps be improved. If that msg were (1) more visible and immediate and (2) said more about what is invalid (even just pointing out that here `quote' is taken as a face name or whatever), that might help. > So I still don't see a problem with the documentation in this case. See above. We could maybe help users a bit more, without giving up any of the exactness of the spec given in `Special Properties' etc. > 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*. =20 Yes, now we're thinking along the same lines. The real problem is the interaction with the user and the inadequacy of the message, IMO. > However, that doesn't seem to be a bug: > the face spec is invalid,=20 Yes, but can we say why, in what way, what about it is invalid? (If the doc in question actually referred to "face spec" instead of "face" or "face representation", that would be a start. It would guide user toward the part of the doc that says what can be in a face spec.) > 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). I was afraid you might say that. All I can say is that if we can possibly do something better that would help. There are gotchas in Emacs that we can't really prevent or guide users away from (e.g. using existing names of things in perverted, misleading ways). I was hoping this is one where we might be able to help a bit. > > 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? >=20 > Tell users to read the docs? But we already know > that doesn't really work... In this case, the problem (IMO) is that the doc they are led to doesn't guide them to the doc that really helps with this. See above.