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 Date: Sun, 10 Jan 2016 09:55:57 -0800 (PST) Message-ID: <74e37b32-1c4c-42b2-a98e-ab3ea7086e2c@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> <56922DDC.1080702@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452448593 28670 80.91.229.3 (10 Jan 2016 17:56:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 17:56:33 +0000 (UTC) To: =?iso-8859-1?B?Q2zpbWVudCBQaXQtLUNsYXVkZWw=?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 18:56:21 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 1aIKE0-0003bU-GO for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 18:56:20 +0100 Original-Received: from localhost ([::1]:48292 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKE0-0006hr-3R for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 12:56:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKDm-0006hm-EU for emacs-devel@gnu.org; Sun, 10 Jan 2016 12:56:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIKDh-0004hS-Ee for emacs-devel@gnu.org; Sun, 10 Jan 2016 12:56:06 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:35114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIKDh-0004hO-84 for emacs-devel@gnu.org; Sun, 10 Jan 2016 12:56:01 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0AHtxrY019449 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 17:56:00 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0AHtwj9030236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 10 Jan 2016 17:55:59 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0AHtwi3006732; Sun, 10 Jan 2016 17:55:58 GMT In-Reply-To: <56922DDC.1080702@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:197987 Archived-At: > I think this is converging to what Stefan pointed earlier (which I found > very convincing/exciting): in its most basic form, this proposal could > supersede a lot of ad-hoc checking that many many commands do (by calling > `barf-if-buffer-read-only', for example). Those commands still need to do that in their bodies, for the same reason that a command does it in the body today, even when it might also do it in the `interactive' form (e.g., to prevent further processing of an `interactive' form that reads multiple inputs). Regardless of how or where or why such a function is invoked, it needs to raise such an error and let the user know what the invocation problem is. Preventing a function from being calling incorrectly (in your view) interactively does not prevent it from being called incorrectly (in your view) non-interactively. > Similarly, there are many commands that are marked interactive because > they are bound to keys in certain contexts, but make no sense (and will > just immediately error out if called from M-x) otherwise. The way we handle that normally is for such keys to be bound in a mode map. If you are in that mode then they are bound to those context-specific commands; otherwise, no. In such a case it makes sense to not make those commands available on key bindings outside of the mode. That rationale is entirely absent for the case of `M-x', which is (and should be) completely general. Leave it to the context-defining mode to decide whether a given command should be bound in that context. Don't cripple `M-x'. > I find it reasonable to think that if a command is just going to > exit in error as soon as I call it I probably don't want it to > feature prominently among M-x completions. 1. But the proposal now being considered goes far beyond not showing it as a command-name completion for `M-x'. It is no longer about the possibility of _completion_ but is instead about the possibility of _invocation_ - in any way (IIUC). 2. Sometimes a user wants to see what commands exist (e.g. match a given pattern), whether or not a given command can be used in the current context. Completion lets you see what the matching command names are, irrespective of whether you might want to invoke a particular one - or any one. It is up to the particular _command that is completing_ function names to match input to decide whether to remove some names from the outset. `M-x' is one particular command that completes function names. But it is the most general command-invoking command we have. It should not filter beyond `commandp' at the outset. But a user could well be given minibuffer keys that let the _user_ filter `M-x' candidates in additional ways. 3. A user might well _want_ to see the specific error message, in particular because it might not be obvious _why_ (in your view) a given command name is not available as a candidate. Making `M-x' filter out certain candidates beforehand tells the user _nothing_ about (a) whether such commands exist or (b) why they are currently considered unavailable. IOW, less help for a user.