From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx) Date: Sun, 10 Jan 2016 15:27:10 +0000 Message-ID: <20160110152710.GB3580@acm.fritz.box> 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: 8bit X-Trace: ger.gmane.org 1452439516 24199 80.91.229.3 (10 Jan 2016 15:25:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 15:25:16 +0000 (UTC) To: Yuri Khan , Drew Adams , =?iso-8859-1?Q?=D3scar?= Fuentes , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 16:25:07 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 1aIHre-0007s1-GT for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 16:25:06 +0100 Original-Received: from localhost ([::1]:47220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIHra-0001Yi-AO for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 10:25:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIHrV-0001YW-P4 for emacs-devel@gnu.org; Sun, 10 Jan 2016 10:24:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIHrS-0006Ot-Ff for emacs-devel@gnu.org; Sun, 10 Jan 2016 10:24:57 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:45354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIHrS-0006M8-6R for emacs-devel@gnu.org; Sun, 10 Jan 2016 10:24:54 -0500 Original-Received: (qmail 86787 invoked by uid 3782); 10 Jan 2016 15:24:52 -0000 Original-Received: from acm.muc.de (p548A4E8E.dip0.t-ipconnect.de [84.138.78.142]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Jan 2016 16:24:48 +0100 Original-Received: (qmail 4673 invoked by uid 1000); 10 Jan 2016 15:27:10 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:197965 Archived-At: Hello, John. On Sat, Jan 09, 2016 at 12:55:28PM -0800, John Wiegley wrote: > >>>>> Yuri Khan writes: > > Emacs already contains a feature that filters out many defined functions > > from M-x. It’s called (interactive). Functions that are not declared > > interactive are not offered as completion candidates, and in fact cannot be > > executed with M-x. > OK Yuri, now you've got me excited. 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. What you're proposing is exactly "filtering M-x"; censoring it, if you will; a sort of "not in front of the children" attitude that restricts what you can see by somebody else's criteria. I think most people on this list would be opposed to censorship in most areas (for example, national authorities deciding what part of the WWW is suitable for browsing). Yet, here we are, talking about introducing the same sort of thing into Emacs. This might be OK if the only reason you every use M-x is to execute a command. But it's not. People (in particular, me) use it to discover Emacs, to find the exact name of a command which has only vaguely embedded itself in the memory, to get this name into the kill ring to be yanked into another source file or into documentation, and so on. Try M-x sometime, and explore the wealth of Emacs commands. :-) > 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. If it is to be implemented, then the right place is indeed in core. But just because we can implement it doesn't mean we should. It would add, marginally, to the complexity of Emacs, to the difficulty of learning it. What do we gain that would offset this loss? What is this feature for? People have suggested filtering by mode, by read-onliness, and so on. Somebody (I think it was Artur M.) even suggested removing initial checks from commands, on the grounds that M-x filtering would render it unneeded. I don't think that could ever be the case. > 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 ]) > 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 silently > 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. > At first, I imagine nothing delivered with Emacs will be conditional, because > it requires annotating packages retroactively. 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). At which point I see the complexity rapidly increasing, unforeseen Bad Things happening, and generally a lot of pain. > The use of such automation would be configurable and off by default, > at least until we believe it's ready for prime-time. _ANY_ form of censorship must be optional, and not merely up to the point where some authority decides it's acceptable to impose on the masses. > Thus, proper UI behavior for M-x falls out by design, and we get to make use > of conditionality for other purposes, such as better errors when command > functions are called outside their expected environment. Any chance of an example of such an improvement? How are we to improve on, for example, "Can't execute - not in Foo mode"? > I'm open to a feature branch implementing such conditionality, as a candidate > for merging to master. As described above, I expect the C code impact to be > fairly minimal, and the changes to `M-x' to also be minor. The automation > logic seems like the trickiest part, as it would have to happen whenever a > feature is loaded. Again, what is this feature for? Is it going to make editing easier for experienced users? Is it really going to attract new users, ones who would be very happy in Emacs but for the huge number of commands presented to them in an M-x? I'm sceptical on both counts. > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 -- Alan Mackenzie (Nuremberg, Germany).