add `completing-read-history'

add `completing-read-history'

[Drew Adams]

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?

Re: add `completing-read-history'

[Richard Stallman]

    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).

I don't like the idea of complicating minibuffer input or taking away
commands in cases where there is no real set of valid completions.

RE: add `completing-read-history'

[Drew Adams]

>     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).
>
> I don't like the idea of complicating minibuffer input or taking away
> commands in cases where there is no real set of valid completions.

I'm not sure what you're saying. You seem to say:

. That would complicate minibuffer input. Why? If you didn't hit TAB, then
there would be no change. OK, to insert a TAB char you would need to hit
C-q, so I guess that complicates things slightly. Also, for `?', since Emacs
doesn't allow `?' for input during completion. Also, for ` ', except for
filenames, for the same reason. (Better that Emacs should allow `?' and ` '
as input during completion, IMO.)

. That would take away some other commands. What commands would be "taken
away"?

. These bad things would happen when there is no real set of valid
completions. I don't know what that means. Can you give an example?

No one would be forced to use `completing-read-history' in a context where
such bad things might happen. It would be available for use in other
contexts.