-------- 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 To: Stefan Monnier 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 , 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