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

[Boruch Baum]

-------- Forwarded Message --------
Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting
hist parameter
Date: Wed, 11 Mar 2015 17:17:10 -0400
From: Boruch Baum <boruch_baum@gmx.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>

On 03/11/2015 03:19 PM, Stefan Monnier wrote:
>>> 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).
We clearly have a communication problem here, as my attempts to explain
my point have failed.

>> - 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.
Good example. Understood.

>> 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).
You had suggested that a user who did not want to see duplicates in
mini-buffer scrolling within commands such as `toggle-option' or
`highlight-regexp' should set variable history-delete-duplicates to t.

The command history acts as a log of commands, so there is benefit there
is maintaining duplicate entries for the purpose of reviewing one's past
activity. (eg. M-x <up-arrow>, or M-: command-history). This is quite
different than the desirability of having those duplicates display as
options within a command such as `toggle-option' or `highlight-regexp'.

-ALSO-, the command-history isn't the only history list (with potential
duplicates) that could be used. You referred above to file-name-history,
and there are many others (eg. face-name-history, or apropos-variable
.*-history$ / .*-ring$ ).

> 
>> 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.
Currently, scrolling forward shows elements of COLLECTION, and scrolling
backwards shows elements of HIST, so there's no need to resort to
completion, just scroll forward. You are correct, though, that the
desirable functionality is for scrolling, in either direction, offer all
possible choices. That is exactly the point.

> 
>> 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.
Correct. I don't think I ever claimed so. This seems to be another
example of our communication difficulty.

> 
>> It would only delay your ability to see all your options.
> 
> Agreed, which is why I'd expect the user to use completion instead.
I just tried this for both functions `highlight-regexp' and
`toggle-options'.

In the first case, the result was highly undesirable in that it took a
long time to construct the completion buffer, and that it was
incorrectly populated with 606 face options, when COLLECTION (the
variable hi-lock-face-defaults) contains only six entries.

In the second case, the completion buffer was constructed quickly and
correctly with the contents of variable `toggle-option-list'.

>> 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".
That's not what I'm reading in the documentation. What I see in the
current documentation is only a discussion of HIST=!nil. In any case, an
alternative option would be another value of your choice, besides t.

Regards,

Boruch.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

signature.asc
Description: OpenPGP digital signature