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: Ordering of command completions Date: Sun, 7 Dec 2014 12:42:42 -0800 (PST) Message-ID: <99caf488-cdcb-4897-9a94-393bcbf36326@default> References: <87zjaztimi.fsf@wanadoo.es> <0c854b9e-16a9-4147-8a82-3ad94b6790f0@default> <87r3wbtfn9.fsf@wanadoo.es> <2559f693-8b4b-40c7-b3b4-4b5d932c377c@default> <87mw6ztdhc.fsf@wanadoo.es> 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 1417984991 7079 80.91.229.3 (7 Dec 2014 20:43:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 20:43:11 +0000 (UTC) To: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 07 21:43:04 2014 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 1XxifY-0004DZ-1l for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 21:43:04 +0100 Original-Received: from localhost ([::1]:59117 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxifX-0006JD-Mz for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 15:43:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxifN-0006Ix-27 for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:43:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxifE-00084U-B0 for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:42:53 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:51332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxifE-00084P-3t for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:42:44 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB7KggVA009350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Dec 2014 20:42:42 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB7KgeTZ010087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Dec 2014 20:42:41 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7KgeJs021469; Sun, 7 Dec 2014 20:42:40 GMT In-Reply-To: <87mw6ztdhc.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:179300 Archived-At: > > I don't think Emacs should be overly ambitious here in excluding > > commands. It should instead exclude only commands that it is > > absolutely sure no user would be able to use in the current > > context. What "context" means here is probably the real question. >=20 > Well, if the command definition comes with an attached statement > about its applicable context ("when such mode is enabled") Emacs > has a definitive method for the decision. OK, yes. It's not always good for the code of a command (which I guess is where this declaration resides) to preclude where it might be invoked. But I guess this is no different in that regard than the command raising an error if not in the desired mode. So I don't have a problem with this way of making it known to `M-x' that a command is "inappropriate". In that case, why only move it to the end of the sort order, instead of completely excluding it as a candidate? Presence as a candidate affects completion (e.g. whether there is a match). > > To me, if you have loaded a library that defines commands that > > you can invoke currently (which, a priori is the case for most > > commands), then I *want* `M-x' to include those commands when > > my input matches their names. >=20 > I was thinking about this scenario: the user is happily hacking on C > code, then he starts Gnus, reads for a while, quits the Gnus session > and comes back to his C hacking. Now M-x lists hundreds of gnus-* > functions such as gnus-summary-expire-articles-now, which only > applies to a Gnus Summary buffer. This is a net negative contribution > to the usability of M-x. Yes, but whose fault is that? ;-) Just kidding. If Gnus declares its stuff invocable by `M-x' only when in some Gnus mode, I agree that that is an improvement. But in that case, it should not just be about sort order. The noise should be removed altogether, if it is truly inappropriate outside of some context. Sounds good to me, I guess. Is there a way for a user to advise such a command to change or remove the declaration? Is `declare' amenable to advising?