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: Limit what M-x TAB lists? Date: Sat, 11 Jan 2014 15:38:03 -0800 (PST) Message-ID: References: <87bo03itkn.fsf@building.gnus.org> <87vbxqjkht.fsf@spindle.srvr.nix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389483518 28006 80.91.229.3 (11 Jan 2014 23:38:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 23:38:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nix , Tom Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 12 00:38:43 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 1W288Z-0006nD-Ib for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 00:38:43 +0100 Original-Received: from localhost ([::1]:35885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W288Z-0003tq-5F for ged-emacs-devel@m.gmane.org; Sat, 11 Jan 2014 18:38:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W288P-0003tc-5Q for emacs-devel@gnu.org; Sat, 11 Jan 2014 18:38:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W288D-0003ie-4g for emacs-devel@gnu.org; Sat, 11 Jan 2014 18:38:33 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:43353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W288C-0003iL-Tk for emacs-devel@gnu.org; Sat, 11 Jan 2014 18:38:21 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0BNc9lg028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jan 2014 23:38:10 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0BNc87a017148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 23:38:09 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 s0BNc8hW012425; Sat, 11 Jan 2014 23:38:08 GMT In-Reply-To: <87vbxqjkht.fsf@spindle.srvr.nix> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:168133 Archived-At: > > An alternative approach can be changing the order of items. > > The more frequently a command is used the higher it would be > > listed, so your most frequently used commands would float to > > the top of the completion list and you'd find them easier. >=20 > FWIW, Icicles can do this (it also fontifies commands you've > used at all differently from those you have not). >=20 > (Icicles is so different from normal completion that I'm not > even sure I should be mentioning it. But still.) Why not mention Icicles? It shouldn't be hard to do things in vanilla Emacs that are similar to Icicles features. Where there's a will there's a way. (And FWIW, Icicles completion is less different from "normal" completion than is, say, Ido completion. Icicles completion is pretty much a superset of "normal" completion. Unlike Ido, it uses the minibuffer and *Completions* "normally". If you don't hit extra keys then the behavior you get is pretty "normal".) First, a comment on the above suggestion that Nix replied to: IMO, systematically floating more recent inputs to the start of a completion list would take control away from the user, unless it it is easy to turn off that behavior (e.g., while completing). What Nix says about Icicles is correct. But the following info might not be obvious, and it might help in this context. Items 1-7 are about sorting; 8-9 are about minibuffer histories. All of what is said here applies to all kinds of completion, not just command completion (`M-x'). 1. Users control the sort order, and can change it on the fly at any time. Likewise, reversing the current sort order. 2. Some sort orders are available as choices for all types of completion. Others are specific to particular completion types (e.g. file-name completion) or even to particular commands. It is easy for a command to make use of a given set of sort orders. 3. You can choose a different sort order (or no sorting) by cycling among orders or by matching their names using completion. You use `C-,' to do this. Cycling is quick when there are not many orders to choose from. Completion can make sense otherwise, and when there are some orders you do not want to enable. (Some orders are more costly in time - they are called out in the doc.) A user option defines a threshold, at or below which cycling of sort orders is used by default and above which completion is used by default. The default threshold is 7 sort-order candidates. A prefix arg flips the behavior: if `C-,' would currently cycle then it completes instead, and vice versa. 5. In addition to choosing another sort order, you can toggle between the current sort order and the current alternative sort order - a quick way to flip between two orders. You can choose different alternative sort orders in the same ways you choose the current sort order: cycling or completion. By default, the alternative sort order puts previously used inputs first, sorting those candidates and the others alphabetically. 6. You can easily define additional sort orders or remove existing sort orders from the base set. 7. You can even combine existing sort orders interactively, melding them together in various ways. 8. You can toggle the highlighting that Nix mentioned for previous inputs, anytime from the minibuffer. 9. There are two ways to limit completion candidates to those that have been input previously: * `M-pause' resticts the currently matching candidates to ones that have been entered before. * `M-h' matches minibuffer content against previous inputs. More info: * http://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates * http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements