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: Mon, 11 Jan 2016 04:02:16 -0800 (PST) Message-ID: <24db4424-1491-4da3-bfdf-d0a604f70a8b@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> <96ccb9a0-d9a0-4c8b-9d19-b3a051d31f77@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 1452513789 22300 80.91.229.3 (11 Jan 2016 12:03:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Jan 2016 12:03:09 +0000 (UTC) Cc: Emacs developers To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 11 13:02:57 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 1aIbBY-000764-CI for ged-emacs-devel@m.gmane.org; Mon, 11 Jan 2016 13:02:56 +0100 Original-Received: from localhost ([::1]:53442 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIbBX-0004Yc-Li for ged-emacs-devel@m.gmane.org; Mon, 11 Jan 2016 07:02:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIbB3-0004Vd-G4 for emacs-devel@gnu.org; Mon, 11 Jan 2016 07:02:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIbAy-0004wD-Be for emacs-devel@gnu.org; Mon, 11 Jan 2016 07:02:25 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:47936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIbAy-0004vy-4P; Mon, 11 Jan 2016 07:02:20 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0BC2IMk028005 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 12:02:18 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0BC2Hqm012276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 12:02:17 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0BC2H8D028307; Mon, 11 Jan 2016 12:02:17 GMT In-Reply-To: <96ccb9a0-d9a0-4c8b-9d19-b3a051d31f77@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] 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:198022 Archived-At: I do think that there can be some value in letting commands, such as `M-x', that provide completion for command names, take invocation-context information into account. I think we should be more specific about what is involved - how this is done. And I think we should be more flexible than what I've heard proposed so far. In particular, we should be flexible about how such invocation-context info can be provided and used. Let me make a hopefully more constructive contribution to the suggestions about this than what I've written so far. Here's how I see such a new feature. 1. It would: a. Provide information about a specific command regarding its invocation contexts. This info can indicate which contexts "make sense" or which do not. But it can also indicate anything else about a context in which one might try to invoke the command. The form of the info would be a Lisp sexp, and a value of nil would be equivalent to an absence (no context information). Its interpretation would be up to (1b) - no fixed or predefined interpretation. b. Use this information in `M-x', and possibly in other contexts. (I'll write `M-x' for short, but this should be understood as any context that uses the (1a) info. And even when thinking of it as `M-x, understand a new, `M-x'-like command.) 2. (1a) and (1b) are two different things, and we need not be rigid about either their relationship or just how `M-x' or other contexts might use the (1a) info. 3. The (1a) info can be a predicate that `M-x' can apply to each completion candidate. It can use the resulting value to remove the candidate or to display it differently or to do something else that is specific to it. Likewise for any other (1b) context: it is up to that context to do with info (1a) whatever it wants. 4. The (1a) info could be something other than a predicate and nil. This is left unspecified, but it should not be assumed that it is always a function. 5. A predicate return value of nil, or an absence of (1a) info for a given candidate, would mean treat the command candidate normally (classically). A non-nil return value would mean treat it specially in some way - see (3). 6. The predicate can test anything. It should be possible to invoke it with any number of arguments, which are unspecified. It can access the target command's symbol as the value of variable `current-cmd' (or some better name). (We could require passing the command as a first argument, but that would make using some existing predicates more cumbersome.) 7. It should be easy to add, modify, or remove info (1a) from a command using Lisp at any time, and without modifying or otherwise accessing the source code that defines the command. 8. The command's `interactive' spec is not the right place to provide the (1a) info (e.g. predicate). This is not about interactive use in general. It is info about invocation contexts. A `declare' form is also the wrong place for the (1a) info. It should be possible to create or remove such an association in source code but also interactively (e.g., using `M-:'). 9. I propose putting info (1a) on the command symbol as a property. This is a limitation only for commands not associated with a name (which are not used by `M-x', at least). Example: (put 'kill-line 'cmd-context (lambda (cmd) (not buffer-read-only))) This association is purposely separate from the defun. 10. `execute-extended-command' (`M-x') would provide its usual behavior by default. A user option would let it take info (1a) into account. Later, the default behavior (and default option value) could be switched if we decide that is better. 11. We can provide a minibuffer key, when `M-x' is used, to toggle the option value (for (a) the `M-x' duration or (b) definitively, so that it effects subsequent `M-x'). A user might do this for clarity, or to see more context info or more candidates, or to improve performance if taking (1a) info into account slows things down appreciably. 12. When `M-x' takes info (1a) into account, it treats a completion-candidate command name specially if info (1a) is present, according to the value of a user option (e.g., `cmd-context'). Possible behaviors could include: . Removing the command as a completion candidate if info (1a) is a predicate and invoking it returns nil. . Showing the (1a) info (e.g., the predicate sexp or symbol) next to the candidate command in *Completions*, as an annotation. . Displaying the candidate in a different face according to the nature of info (1a). E.g., if a predicate and invoking it returns nil, then dim the candidate. 13. Since a given (1b) context such as `M-x' can do anything it likes with (1a) info, it could, in particular, handle that info differently depending on the current set of completion candidates. For example, it could automatically turn off taking (1a) info into account when the number of candidates is particularly large or small. 14. If a (1b) context such as `M-x' wants to improve performance by, say, byte-compiling a (1a) predicate, it can do so, but it must not replace the source (1a) value, which should remain a Lisp sexp. This is so we keep things flexible and we do not shut the door on possible uses of info (1a).