emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

add `completing-read-history'


From: Drew Adams
Subject: add `completing-read-history'
Date: Sat, 23 Jun 2007 11:02:22 -0700

IMO, it's good to encourage Emacs-Lisp programmers to use completion more
for reading user input. I suspect that some of us use `read-string' and
`read-from-minibuffer' in situations where we might advantageously use
`completing-read' (or another read-with-completion function).

Even in my Icicles code, for instance, where I emphasize completion
throughout, there were places where I simply read a string value, so I used
`read-from-minibuffer' or `read-string'.

Now, I instead use a function that lets users complete input against an
input history. This has the advantages that the user can easily see past
inputs of the appropriate kind, match against them, pick one, and possibly
edit it. The completion is lax (permissive), so s?he can ignore completion
if s?he likes. In that case, this acts like `read-string' or
`read-from-minibuffer'.

Here's the definition I use:

(defun completing-read-history (prompt &optional hist pred
                                init-input def inherit-input-method)
  "Lax `completing-read' against entries in history HIST.
Arguments are as for `completing-read'. HIST is a symbol that is a
history variable. It defaults to `minibuffer-history'. Completion is
lax: a match is not required."
  (setq hist (or hist 'minibuffer-history))
  (completing-read
    prompt
    (mapcar #'list (icicle-remove-duplicates (symbol-value hist)))
    pred nil init-input hist def inherit-input-method))

(Any non-destructive remove-duplicates function that uses `equal' will do.)

This doesn't replace `read-from-minibuffer', of course, in situations where
you pass a KEYMAP, READ, or KEEP-ALL argument to the latter. And I'm not
suggesting that we should replace `read-string' either. But I do think that
many programmer uses of these two functions could be replaced to advantage
by calling this instead. Even the KEYMAP arg to `read-from-minibuffer' is
sometimes used just to pass a minibuffer completion table (to provide
completion), and some of those cases too could take advantage of this
function.

(I suspect, BTW, that many programmers never think of passing a completion
map for arg KEYMAP - I know that it took me a while to realize that I could
do that. It might be good to point this out in the Elisp manual, and to add
a cross reference to that text in the section on completion.)

I think it would be useful for Emacs to add such a function and encourage
its use (over the non-completing read functions). Too often, I think, we
don't let users take advantage of completion when they could. Sometimes,
perhaps, that's due to laziness in looking for a good TABLE argument to
provide suitable completion candidates. There is nearly always a history set
that is appropriate, however.

Yes, users can already access history items when inputting to `read-string'
and `read-from-minibuffer' - they can cycle and search the history. But the
advantages listed above are not there: (a) seeing all past inputs that match
what you've typed so far and (b) completing against them. Even if a user
decides to use the history just as s?he would today with `read-string' or
`read-from-minibuffer' (i.e., cycle or search it), just being able to also
see the history entries is helpful. And in *Completions* the history entries
are sorted alphabetically, which can also be an advantage in choosing (you
still have the chronological order available for history cycling and
search).

These advantages weigh more when substring and regexp completion are
available and when users can change the *Completions* sort order on the fly,
but I think these advantages are also important for Emacs's standard
(prefix) completion.

WDOT?







reply via email to

[Prev in Thread] Current Thread [Next in Thread]