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#24237: 24.5; (elisp)`Extended Menu Items', :filter warning Date: Sat, 12 Dec 2020 12:45:17 -0800 (PST) Message-ID: <70cc884d-4f32-4a2e-b3f5-181709f2ca29@default> References: <6c4f5089-43fa-4ca1-a656-1ec1684df960@default> <87v9d67ox6.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5085"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 24237@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 12 21:57:14 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 1koBx3-0001Cj-3R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Dec 2020 21:57:13 +0100 Original-Received: from localhost ([::1]:56976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koBx2-0004Io-3T for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Dec 2020 15:57:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koBmE-0007QF-Na for bug-gnu-emacs@gnu.org; Sat, 12 Dec 2020 15:46:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35303) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koBmD-0003es-Sc for bug-gnu-emacs@gnu.org; Sat, 12 Dec 2020 15:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koBmD-0004Hq-R9 for bug-gnu-emacs@gnu.org; Sat, 12 Dec 2020 15:46: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: Sat, 12 Dec 2020 20:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24237 X-GNU-PR-Package: emacs Original-Received: via spool by 24237-submit@debbugs.gnu.org id=B24237.160780592616424 (code B ref 24237); Sat, 12 Dec 2020 20:46:01 +0000 Original-Received: (at 24237) by debbugs.gnu.org; 12 Dec 2020 20:45:26 +0000 Original-Received: from localhost ([127.0.0.1]:46846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koBle-0004Gq-FE for submit@debbugs.gnu.org; Sat, 12 Dec 2020 15:45:26 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:57224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koBld-0004Gd-5J for 24237@debbugs.gnu.org; Sat, 12 Dec 2020 15:45:25 -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 0BCKjJYd036118; Sat, 12 Dec 2020 20:45:19 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=fA530xD79HN+C0GdUYXg9MgIwFpmZR/p17KYnSTQrCo=; b=Nj0OoDapiO9WnyB6KSPe1gfFLiVedqxQI0jKtb+QONNKgeXDLDZIiJdy6oRtS4/FHi1T uDDOBHtFhbQNDkAAwn84dimIHWSIrvsaD0JmXXDNdha/AqeKN9FEAk/Bu+0Aq7F1r4KH MX3OWu1aFrP49SfD2uhz+1UNyTcmb7ImMeE9rlTOgMonFEnuF7G9WCLcF5n+k407lxti 3sgkLTSvGhAeaqDHMjBIJAahmOCnHgZ7sw8oYI2mnENgwJuejQMIEzwNo3V3MPqDM35g tDrjo1IEambP2fgktbp5eMe+I3u7DS2yrjIxVOoDaTBBmvNRtDtYb9vehGqkluyEpWco Hg== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2130.oracle.com with ESMTP id 35ckcb1e4g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 12 Dec 2020 20:45:19 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BCKf09b165271; Sat, 12 Dec 2020 20:45:19 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 35ckw8uhr1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 12 Dec 2020 20:45:19 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BCKjIlf007290; Sat, 12 Dec 2020 20:45:18 GMT In-Reply-To: <87v9d67ox6.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5071.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9833 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012120162 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9833 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012120162 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:195896 Archived-At: > > The doc for :filter says this about the FILTER-FN: > > > > Emacs can call this function at any time that it does redisplay or > > operates on menu data structures, so you should write it so it can > > safely be called at any time. > > > > Is this true in general, or only when the extended menu item is put on = a > > menu? > > > > A common idiom is to make use of a `menu-item' construct with a :filter > > to create a conditional _keyboard_ key binding. In such a case, the > > `menu-item' construct is not a real menu item - it is not placed on any > > menu. > > > > I'm guessing that in such a case this doc paragraph does not apply. If > > this guess is correct then please correct the paragraph, so that it say= s > > something like "If an extended menu item that uses :filter is placed on > > a menu then Emacs can call FILTER-FN when...". >=20 > I think making the documentation more specific here serves no purpose. > The statement as is should be true: You should always write these filter > functions as if they are called at any time. >=20 > > Also, is it really the case that FILTER-FN can be called anytime Emacs > > does redisplay? Shouldn't the doc say only that it can be called > > anytime Emacs "operates on menu data structures"? Does it get called b= y > > redisplay other than when redisplay operates on menu data structures? > > In the case mentioned above (binding to a keyboard key), would FILTER-F= N > > ever be called during redisplay? I'm guessing that it would not. >=20 > I don't see why we should specify that at all. The Elisp manual is not only for readers reading as end users. This information is needed by people writing Lisp code that uses extended menu items. And as the bug report points out, a very different use case does not involve use of a menu at all. Now perhaps Emacs should provide some alternative to using an extended menu item, specifically for this very different use case. But until and unless it does that, the behavior for this particular use case should be covered in the doc. In particular, if the caveat that is written does NOT apply for this use case, then that should be pointed out. IF the guess is correct that this caveat does NOT in fact apply to this use case then no, it is NOT the case that "You should always write these filter functions as if they are called at any time." If that guess is correct then what you say as the reason for not fixing this doc bug simply isn't relevant. This is not some obscure detail. It goes to the heart of the behavior and use of extended menu items. If you instead want to create a new Lisp construct to achieve such filtering for non-menu uses, great - that would take care of this lack in a different, equally (maybe even more) acceptable way. Just ignoring this isn't TRT. I, for one, would like to know what the case really is wrt the display engine problem when you use an extended menu item without a menu.