RE: [External] : Improvement proposals for `completing-read'

[Drew Adams]

> > > One such case is when you 
> > > browse the history itself using `completing-read`,
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > but this is certainly a very narrow case.
> >
> > Why is it even a use case?  Why disable history when
> > `completing-read' against the history?  Maybe you
> > have a good reason - what is it?
> 
> This way, I am browsing ANY history from minibuffer:
> (completing-read "Choose: " '("Jane" "Joe") nil nil nil nil)
> 
> This way, though the documentation does not say something about
> it, but I do not see any history and I do not need to have
> history variable, but function thinks there is history:
> (completing-read "Choose: " '("Jane" "Joe") nil nil nil t)
> 
> So it is effectively "disabled".
> 
> Maybe it was meant here to disable the general minibuffer
> history, but that is obviously easy to do. Other way to disable
> would be to encompass `completing-read' with one `let':
> 
> (let ((history))
>   (completing-read "Choose: " '("Jane" "Joe") nil nil nil 'history))
> 
> Or simply to disable history variable in the program when necessary.

None of what you wrote has to do with what Daniel
posited: use of `completing-read' with a history
list providing the completion candidates.  (That's
at least what I understood him to mean.)  E.g.,

(completing-read "Choose from file-name input history: "
                 file-name-history)

(completing-read "Choose from regexp input history: "
                 regexp-history)

(completing-read "Choose from input history: "
                 minibuffer-history)

I think Daniel was suggesting that it makes sense
in all such cases to use `t' for the HIST arg.  E.g.:

(completing-read "Choose from input history: "
                 minibuffer-history nil nil nil t)

I'm guessing his point would be that without `t'
traversing the history (e.g. with `M-p' or `M-r')
would be a redundant way to get to a completion
candidate, which it would be.

But an alternative way to get to a candidate isn't
a bad thing.

And if the REQUIRE arg is nil then it can even be
useful to use a _different_ history for the HISTORY
arg from that used for the COLLECTION arg.

(Even if REQUIRE is non-nil that might sometimes
be useful - it lets you use `M-p' or `M-r' to get
to candidates that are in both histories.)