From: Drew Adams <drew.adams@oracle.com>
To: Nix <nix@esperi.org.uk>, Tom <adatgyujto@gmail.com>
Cc: emacs-devel@gnu.org
Subject: RE: Limit what M-x TAB lists?
Date: Sat, 11 Jan 2014 15:38:03 -0800 (PST) [thread overview]
Message-ID: <acf03124-0f35-44d3-a5ee-c010642b9a5f@default> (raw)
In-Reply-To: <87vbxqjkht.fsf@spindle.srvr.nix>
> > 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.
>
> FWIW, Icicles can do this (it also fontifies commands you've
> used at all differently from those you have not).
>
> (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
next prev parent reply other threads:[~2014-01-11 23:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-26 14:18 Limit what M-x TAB lists? Lars Ingebrigtsen
2013-12-26 14:58 ` Stefan Monnier
2013-12-26 15:24 ` Lars Ingebrigtsen
2013-12-26 16:03 ` Óscar Fuentes
2013-12-26 16:09 ` Lars Ingebrigtsen
2013-12-26 17:50 ` Stefan Monnier
2013-12-26 18:03 ` Lars Ingebrigtsen
2013-12-27 1:41 ` Lars Ingebrigtsen
2014-01-03 18:00 ` Ted Zlatanov
2014-01-06 15:47 ` Davis Herring
2014-01-18 17:43 ` Lars Ingebrigtsen
2013-12-26 17:50 ` Tom
2014-01-11 21:07 ` Nix
2014-01-11 23:38 ` Drew Adams [this message]
2013-12-27 7:29 ` Stephen J. Turnbull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acf03124-0f35-44d3-a5ee-c010642b9a5f@default \
--to=drew.adams@oracle.com \
--cc=adatgyujto@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=nix@esperi.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.