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: Leaving out non-applicable commands on Mx Date: Sat, 9 Jan 2016 11:27:47 -0800 (PST) Message-ID: <76360e2d-2408-49ef-85c0-e78f88bea596@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 1452367698 598 80.91.229.3 (9 Jan 2016 19:28:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 19:28:18 +0000 (UTC) Cc: =?utf-8?B?w5NzY2FyIEZ1ZW50ZXM=?= , Emacs developers To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 20:28:02 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 1aHzBB-0004Pb-O9 for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 20:28:01 +0100 Original-Received: from localhost ([::1]:42462 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzBB-0000dX-3z for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 14:28:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzB7-0000cR-3n for emacs-devel@gnu.org; Sat, 09 Jan 2016 14:27:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHzB3-0004Sn-Uj for emacs-devel@gnu.org; Sat, 09 Jan 2016 14:27:57 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:24899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzB3-0004Sd-NZ for emacs-devel@gnu.org; Sat, 09 Jan 2016 14:27:53 -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 u09JRlwc018317 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 19:27:48 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u09JRlKK016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 9 Jan 2016 19:27:47 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u09JRlTr028980; Sat, 9 Jan 2016 19:27:47 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:197917 Archived-At: > > And that's also a feature of some "advanced completion > > systems". But it should not (except by user option) be > > the default behavior. The default behavior should be all > > candidates matching the input patterns and the completion > > predicate - no other "helpful" filtering unless requested > > by the user. >=20 > Emacs already contains a feature that filters out many defined > functions from M-x. It=E2=80=99s called (interactive). Functions that are= not > declared interactive are not offered as completion candidates, and in > fact cannot be executed with M-x. You are repeating what I said. I said that it already filters using the predicate appropriate for `M-x' (which is `commandp'). (And in the text you responded to I explicitly said "and the completion predicate" - which for `M-x' is `commandp'.) > This proposal takes (interactive) to a new level, by allowing authors > to specify conditions under which a function should be considered > interactive. Authors can already do that for any command they author that reads command names using completion. They can restrict the candidate commands to any set they like, using an appropriate predicate. That's different from saying that `M-x' should restrict candidates to only commands that an Emacs developer has decided, a priori, are the only ones appropriate for the current context (e.g. mode, buffer, visibility spec, phase of moon, ... whatever). The predicate appropriate for `M-x', which can be used in various ways by users and in many different contexts, is `commandp'. But nothing prevents an author from defining a different command name-reading command that uses a different predicate. And nothing prevents an author from defining a minibuffer key that filters `M-x' candidates further (letting the user decide whether to narrow choices that way). And nothing prevents an author from binding `minibuffer-completion-predicate' to a predicate of choice. Or of binding a completion key (even `TAB') to a command like `minibuffer-complete' but that uses a different predicate or that binds `minibuffer-completion-predicate'. There are all kinds of ways for an author to impose a different set of command-name completion candidates.