RE: read-face-name PROMPT arg should be self-contained, including ": "

["Drew Adams" <drew.adams@oracle.com>]

> >> I was recently thinking that rather than adding new history vars
> >> everywhere all the time, we could change the history navigation
> >> to automatically skip entries which are not completion
> >> candidates (at least for those cases that are `must-match').
>
> > among matches only. Would that be good or bad? For non-`must-match', at
> > least, that might be a nuisance, requiring you to first clear the
> > minibuffer.
>
> You misunderstood.  By "completion candidates" I didn't mean completion of
> the current input, but simply possible completions (i.e. filter
> the history through `test-completion').  Of course.

OK, the current user input would be irrelevant here - got it.

But what do you mean by "filter the history"? Do you mean filter the initial
set of possible completions, to keep only those candidates that are in the
history?

If so, then this would still be limiting for non-`must-match', IIUC. If you
wanted to be able to cycle to a history entry that is not in the initial set
of completions, you could not.

IOW, this would still tie the history list to the set of possible
completions, even if it wasn't the set of completions matching the current
input. Maybe that would be a good thing, maybe not - it's worth thinking
about, at least.

A priori, I tend to think it's good to keep the history list and the initial
set of possible completions separate, allowing access to entries in each
that might not be in the other. But I'd like to hear arguments for linking
the two - it's good that you brought this up.

And, as I mentioned, we should at least _allow_ use of a history variable,
if only for efficiency.

I do agree that it would be worthwhile to provide an easy way to access any
historical input by matching - beyond what M-r does.

I misspoke, BTW, when I said that history matching (M-r) gives you only the
first match. What I meant was that you must use M-r again to access another
match. M-r M-r M-r is not very convenient for rapidly accessing different
matching history items, in order, and you cannot simply type input to match
against all of the history items that match the M-r regexp.

One way to improve on that might be to have successive M-r's not ask for a
regexp, but reuse the regexp that you input for the first M-r. We could then
arrange things so that you could then use just M-r e.*r M-r M-r M-r to cycle
among the history items matching e.*r. A problem with that is that you could
not then use M-r with a different regexp.

An alternative approach, which would not have that problem, would be to make
M-p (and M-n) following M-r (and M-s) cycle among only the regexp matches.
You could then do M-r e.*r M-p M-p M-p, getting the successive matches of
e.*r. A problem with that is that you could not then use M-p to access
historical candidates that didn't match the regexp. You could of course use
M-r .* again to "clear" the regexp filtering (except for \n matches), but
users might not think of that. We could, BTW, change M-r RET to clear regexp
filtering, instead of repeating the previous regexp.

FWIW - In Icicles, I do something different to let you match against the
history: You can type `M-pause' to filter  current matches for your input to
those that are in the history. Or you can type `M-h' to ignore the current
set of completions and match your input against the history list directly.
(Unlike `M-h', after you use `M-pause' you are not locked into matching
against the history list.) You can then complete against the historical
candidates or cycle among them. (Icicles allows regexp matching, so you can
match e.*r against stuff in the history list without using M-r.)

FWIW2 - Tamas Patrovics' library timid.el takes another approach. After a
short delay when you type some input, it pops up the list of matching
history items, without your asking for it explicitly (e.g. via `M-h'). You
can then cycle among the history matches (but you cannot complete to one of
those matches). Rather than being truly timid, doing nothing until asked
(e.g. `M-h'), Timid interrupts whenever there is a sufficient lull in the
conversation - it could be called "suggest.el". The longer the lull,
however, the greater the timidity; you can configure the lull to make Timid
as timid as you like.

What these various features offer are ways to filter the history list and
cycle among those matches (and, for Icicles, to complete against them).
Currently, it is not too convenient to cycle among matches in Emacs using
just M-r.

Both Icicles and Timid let you see the list of history matches, which is
another advantage, I think, over M-r. Especially when trying to come up with
an improved regexp for matching, it helps to see what the current matches
are (and how many there are). Perhaps Emacs could show the list of regexp
matches if you used TAB after you used M-r. (Again, that would require users
to use M-r .* to clear the regexp filtering, so that TAB would work
~normally again.)

Anyway, lots of stuff to think about...after the release.

Refs:
* Icicles: http://www.emacswiki.org/cgi-bin/wiki/icicles.el
* Timid: http://www.emacswiki.org/cgi-bin/wiki/timid.el