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

[Daniel Mendler]

On 4/9/21 7:22 PM, Drew Adams wrote:
> 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.

Yes, you understood me correctly. Note also that if you specify a 
variable, the value of the history variable is modified. When browsing a 
history the desire to avoid modifying the history itself is not 
unreasonable. This means that in any case you would want to use a 
different history variable than the one you are accessing, the history 
of your history browsing.

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

Sure you can do that. You can have a history of your history browsing 
and then a history of your history of your history browsing.

All I am proposing is the removal of the unnecessary restriction of 
disallowing `t` for the HIST argument of `completing-read`. If you look 
at `completing-read-default`, it calls `read-from-minibuffer` directly, 
which accepts this. If you use a different completion system, the 
situation may be different.

Daniel Mendler