bug#7567: Please add a history variable to read-regexp

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

> > I agree with that.  But I also think that it might be good to use
> > `completing-read', to allow (lax) completion against the history.
> > IOW, use the history for both completion and the usual 
> > history access.
> 
> I think this is a bad idea: completing-read is for completion against
> "possible answers" which should be kept separate from
> history-completion.  

I generally agree.  In this case, there was no (is no) other completion, so
there are no other-kind of completion candidates to keep the history separate
from.  But yes, I agree.

> We could/should let TAB perform history 
> completion for non-completing-reads, but if we do that, it should
> be under the control of the user.

Agreed, especially the last part.

I really meant only that it's good in general to have more use of (lax)
completion and less use of things like `read-string' and `read-regexp' that
provide what lax completion provides but without any completion.

> Personally, I think that M-p should perform history completion, and
> that's what my .emacs does.

That would be OK.  The big advantage of completion vs `M-p' etc. is that you can
get more directly to a history entry, no matter how long ago you originally
entered it.

Another possibility - not at all the same thing, but useful in such a case as
well as in others - is what Icicles does: Use another key (`M-o') to let you
complete against the history and insert the result into the minibuffer (without
committing it).  This uses a recursive minibuffer and is available during any
minibuffer input - not just during completing reads.