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:10:06 -0800 (PST) Message-ID: <2559f693-8b4b-40c7-b3b4-4b5d932c377c@default> References: <87zjaztimi.fsf@wanadoo.es> <0c854b9e-16a9-4147-8a82-3ad94b6790f0@default> <87r3wbtfn9.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 1417983041 10242 80.91.229.3 (7 Dec 2014 20:10:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 20:10:41 +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:10:33 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 1XxiA5-0005xQ-8p for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 21:10:33 +0100 Original-Received: from localhost ([::1]:59048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxiA4-00011w-Nj for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 15:10:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56159) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xxi9p-00010q-Tu for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:10:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xxi9h-0005r2-54 for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:10:17 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:47828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xxi9g-0005nn-Sn for emacs-devel@gnu.org; Sun, 07 Dec 2014 15:10:09 -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 sB7KA7EC023257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Dec 2014 20:10:07 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB7KA4GP000997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Dec 2014 20:10:05 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7KA4Xx008124; Sun, 7 Dec 2014 20:10:04 GMT In-Reply-To: <87r3wbtfn9.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:179296 Archived-At: > I use Ido+flx. Yes, as you type the number of candidates quickly > decrease from thousands to dozens, but my experience is that the > vast majority of candidates are not applicable on the current > context and they force you to type quite a bit more. I don't disagree wrt "applicable on the current context", but I'm wary as to what someone might think that should mean. 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. > Then we have non-predictability. You enable a mode through an > autoloaded function and suddenly, for the rest of the Emacs > session, `M-x foo' no longer resolves to the same list of > candidates where it used to. You see? Now that's an example of what I meant by the meaning of "context" being important. 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. If I load a library (or it is autoloaded) then I expect to be able to invoke its commands using `M-x'. I certainly hope that feature is not removed in favor of some "predictability". I am becoming more wary of the proposed change... > > Certainly any command that is bound to a key sequence that > > is available in the current context should be a candidate. > > (That's a minimum.) >=20 > IMHO introducing ad-hoc heuristics for *discarding* candidates > is very risky. That was my point. Emacs needs to be very sure that it makes no sense for a given command to be invoked currently using `M-x', before it thinks about excluding that command. A priori, there are very few commands that can reasonably be excluded, with that in mind. And in that case, little is gained, in terms of reducing the supposed "noise". And something is lost: the user does not see those commands. S?he may well become confused, and think that this or that command has not been defined or is no longer supported or... > OTOH, if it is a matter of sorting the candidates, which is > what the OP suggested, it is fine. I see. I misunderstood. I asked whether by "noise" what was meant was a large number of candidates. I guess the answer is no. It is apparently the position of inappropriate candidates high in the sort order that constitutes "noise", and not their mere presence. In that case I have a different objection. The sorting being used should be *very clear to users*. And in general it should not combine very different criteria, such as (1) appropriateness (one form of which is what this proposed feature is about, I guess) and, say, (2) how recently candidates were used (or some other sorting criterion, such as alphabetic comparison). If sorting combines such different criteria then it can be confusing to users. This is all the more nefarious if a measure of "inappropriateness" is applied unbeknownst to the user. Picking the right candidates to sort lower according to the context can be tricky, and once they are sent to the end of the list a user might well wonder what's going on. I come back, I think, to what I said in the beginning: "the answer (IMHO) is better completion behavior."