RE: [External] : Using completing-read efficiently

[Drew Adams]

[Note: I mention Icicles here not to encourage
 its use, but to describe features - features
 that other libraries could, and sometimes have,
 implement, and that could help vanilla Emacs.]

> Have been using completing-read in the following way.
> 
> I customarily cycle through the COLLECTION items by repeating <down>.
> Having been pointed out to me that cycling is not an efficient
> way to get to something, I would like to try new ways.

To be more correct, what I pointed out was that
it can be inefficient when there are _lots_ of
completion candidates, and especially if their
cycling order isn't particularly helpful.  And
particularly if many of them have a subpattern
in common: if there are 50,000,000 candidates
named John, you want to be able to get quickly
to John Zacharia Zarka.

> One suggestion has been to sort completion
> candidates to tame dumb cycling.
> Being able to filter them is another.

Yes. Use _completion first_, especially if you
can filter multiple times or sort usefully on
the fly.  Use _cycling last_, only after you've
narrowed the choices down to a handful.
 
> Would I need to change the code for sorting and filtering ?
> It would be good to have some instructions on how to use
> such things in practice.

I was referring to features for _interactively_
filtering and sorting, i.e., on the fly during
minibuffer reading (including completing).

When you try to complete (TAB) your minibuffer
input, that text is used to filter the possible
completion candidates.  That's available with
vanilla Emacs, and the kind of matching you get
is governed by, in particular, option
`completion-styles'.

Beyond that, some completion libraries (Icicles,
at least) let you do additional filtering, on
the fly.  Your previous matches become the new
domain of candidates which you can match using
different filter patterns.  The Orderless
library offers something a bit similar.

And some libraries (Icicles again, at least)
let you filter matches out as well as in.
That is, you can hit a key to keep only the
complement of the current matches (relative
to the current complete domain of candidates,
i.e., the matching candidates before the last
filtering, the last one being used to remove,
not keep).
____

OTOH, if you're talking about "filtering"
noninteractively, that amounts to defining
the COLLECTION of candidates to be more
limited, removing candidates you don't want
to provide.  You can do that (1) in the
definition of COLLECTION itself (either as
explicit list/array/hash table or using a
function as COLLECTION value), and (2)
using the PREDICATE argument.

For example, if COLLECTION is the `obarray'
(all symbols) and if PREDICATE is `boundp'
then the candidates are the symbols that
are variables (`boundp', to be precise).
____

As for sorting, I know of no library other
than Icicles that lets you change the sort
order interactively, i.e., on the fly while
completing.  But there may be some now.

[Well, there's also `sortie.el', which is a
 tiny spin-off from the Icicles sorting code.  
 https://www.emacswiki.org/emacs/Sortie
 ]
____

To define the sort order noninteractively
you can of course define COLLECTION to give
you the order you want.  You can also bind
vanilla Emacs vars `cycle-sort-function' and
`display-sort-function'.

(I don't see any reason for displayed order
to differ from cycling order, myself.  Does
anyone?)

> Another aspect has been completion against
> the history. I know absolutely nothing about
> history, though.

Completing against previous minibuffer inputs
is something else.  A given call to a function
such as `completing-read' can use whatever
history list it wants.  The values in that
list need not even correspond to any values
in COLLECTION.  (`completing-read' can be lax,
accepting inputs other than those COLLECTION
provides as candidates.)

Besides completing against a history list,
you can just search it for matches, using
`M-r` or `C-M-r`.  Tried and true, but you
see only one search hit at time, as opposed
to seeing all matches using completion.  And
if your completion has successive filtering
(progressive completion) then you can use
that to narrow the history matches.

One of the reasons to search or complete
input against a history list is that it helps
you access older inputs, saving you some
wasteful, mindless, drone-like cycling.  

Vanilla Emacs now offers some ability to
complete input against the current HISTORY
list, IIUC.  With Icicles there are a few
different ways to do this.

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

HTH.