unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).