bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> If the benefit is limited, it means the problem you mention is
>> correspondingly minor.
> I was referring to the benefit of your idea to filter out !COLLECTION
> elements dynamically, not the bug that offers the user nonsense or
> unacceptable HIST elements in the mini-buffer.

One of the benefits of filtering out elements not in COLLECTION is to
avoid providing "offer[ing] the user nonsense or unacceptable HIST
elements in the mini-buffer".  So if you think the benefit is limited,
it necessarily means that "the bug" is correspondingly minor.

FWIW, I do think it's indeed minor (which is why I haven't written this
filtering yet, even though I've had it in my "wishlist" for quite a while).

> - how could one REQUIRE-MATCH=t against a COLLECTION of infinite size?

Theoretical answer: let COLLECTION be the set of strings that represent
a natural number.  It's infinite, and it makes sense (for example in
read-number) to use REQUIRE-MATCH=t with it.

Practical answer: read a file name in order to delete it.
The corresponding COLLECTION is as good as infinite (especially if you
include remote hosts via Tramp), and you do want to use REQUIRE-MATCH=t
since you don't need to let the user delete a non-existing file.

> A user may normally want to retain duplicates in her general command
> history as a record of past activity, but not have those duplicates
> appear in mini-buffer selections that have REQUIRE-MATCH=t.

I'm not sure I understand.  What do you mean by "command history" and by
"mini-buffer selections"?  In my mind, the history stored in the hist
variable is only ever exposed to the user via things like M-p, M-n, so
there's not much difference between "that which is saved in the command
history", and "that which is shown in the minibuffer" (tho dynamic
filtering out of elements not in COLLECTION would change this state of
affair).

> To illustrate, imagine yourself, as a user, scrolling back through a
> minbuffer history in order to see what your legitimate REQUIRE-MATCH=t
> options are.

Right now, scrolling back like that does not show you those legitimate
choices, and after filtering out the !COLLECTION elements, it still
wouldn't show you all the legitimate choices (only those you happen to
have used in the (recorded) past), so if you want to see those
legitimate choices, the user would be expected to use completion instead
of history navigation.

> When would you ever want duplicates to appear in your scrolling?

And I don't understand why this desire (or not) to see duplicates in
this scenario would be different from what it is in those cases where
REQUIRE-MATCH is not t.

> It would only delay your ability to see all your options.

Agreed, which is why I'd expect the user to use completion instead.

> The documentation does provide for HIST=nil, which -IS- a central
> element of the bug report.

It's unlikely this can be changed since it's been documented for ever
and is used by a lot of code.  Hence the need to use another special
value (i.e. `t') to mean "no history".


        Stefan