From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx) Date: Sat, 9 Jan 2016 13:53:02 -0800 (PST) Message-ID: <96ccb9a0-d9a0-4c8b-9d19-b3a051d31f77@default> References: <87mvszdp6b.fsf@gnus.org> <8737u9kv6f.fsf@russet.org.uk> <87fuy7hdc6.fsf_-_@wanadoo.es> <87bn8vh8q4.fsf@wanadoo.es> <4002fc97-5629-4367-8b8f-48b659fefdce@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452377157 7985 80.91.229.3 (9 Jan 2016 22:05:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 22:05:57 +0000 (UTC) Cc: =?utf-8?B?w5NzY2FyIEZ1ZW50ZXM=?= , Emacs developers To: John Wiegley , Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 23:05:43 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aI1dl-00069u-6V for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 23:05:41 +0100 Original-Received: from localhost ([::1]:43563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI1dk-0007NP-Kl for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 17:05:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI1Rm-0000Sz-2f for emacs-devel@gnu.org; Sat, 09 Jan 2016 16:53:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aI1Ri-0002FO-0S for emacs-devel@gnu.org; Sat, 09 Jan 2016 16:53:17 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI1Rh-0002Ey-QG; Sat, 09 Jan 2016 16:53:13 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u09Lr4Oe006827 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 21:53:06 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u09Lr3Mm002723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 21:53:03 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u09Lr3mN017588; Sat, 9 Jan 2016 21:53:03 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197938 Archived-At: > Let's not talk about "filtering M-x"; let's talk about making > `interactive' conditional. The former is a UI concern, while the > latter I consider a core API issue. >=20 > Right now, functions are interactive if declared with `interactive', and > not otherwise. The suggestion at hand is to allow `interactive' forms to > become conditional -- possibly in multiple ways. I like this concept, > and think the right place for it is indeed in core. >=20 > The question is how to declare such conditionality. We can do this rather > easily by accepting new keyword arguments to `interactive': > (interactive "sDirectory: " [:mode foo-mode] [:when ]) >=20 > This way, all new modes can take advantage of this support as it becomes > available. I've already tested on 24.5, and keyword arguments are silentl= y > ignored by present-day GNU Emacs. This gives us transparent compatibility > in both directions. We could also do it with (declare); I'm open to that = too, > and it also gives us such compatibility. Is this supposed to affect `interactive' only for minibuffer input that is read with completion? If not then it's no longer just about filtering completion candidates. And in that case, just what is conditional? And what about interactive uses that do not read input at all? Does it apply to those cases also? Are you perhaps suggesting that a given function would not be a command (not interactive) when the given conditions are not satisfied? If so, does that mean that a predicate such as `commandp' would also test the given conditions in the current context, i.e., generally (no matter how/where that predicate is invoked)? What kinds of predicates (conditions) would be allowed here? I guess: . You've indicated (in effect) testing the current mode, which amounts to a predicate that accepts the mode as argument and tests with `eq' against the specified `:mode'. . You've indicated that an arbitrary function could be provided (after `:when'). It seems this would thus not be a predicate that is applied to an _individual_ completion candidate. So if you wanted to use it to filter candidates then it would presumably need to invoke `all-completions' (or equivalent) for null input ("") to get all of the initial candidates, and then explicitly filter them. Is that what you are suggesting? What you describe is not yet clear, to me at least. > At first, I imagine nothing delivered with Emacs will be conditional, > because it requires annotating packages retroactively. Doesn't it ("just") require changing `interactive' specs wherever you want this? > We could alleviate some of that by writing code to automatically > consider every interactive function *without an autoload token* as > being conditional on any modes defined in the same package (likely > determined by prefix matching). So you would take the proposal about additional `M-x' filtering and extend it past `M-x' to all uses of interactive functions? A priori, the arguments I cited against doing this for `M-x' would apply a fortiori for such a general treatment. But it's all too vague for the moment to guess what the consequences really might be. In general, my view is: . If it gives library authors more control over the behavior, not less, then it's likely a good thing. . If it gives users even more control over the behavior then that's likely even better. . If instead it hard-codes behavior decided ahead of time by Emacs Dev then it's likely not such a good thing. > The use of such automation would be configurable How? By whom? When? (user options? runtime interactively?) > I'm open to a feature branch implementing such conditionality, Could you please specify it first, at least in some more detail than what you've described so far? I'd start with the question: What is the aim? What is the real problem that you want to fix, or the needed missing feature that you want to provide? IOW, what's it for? what good is it?