* bug#12331: 24.1; completing-read when COLLECTION has exactly one element @ 2012-09-02 1:38 Roland Winkler 2012-09-02 2:49 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Roland Winkler @ 2012-09-02 1:38 UTC (permalink / raw) To: 12331 Suggestion: If the arg COLLECTION of completing-read is a list with exactly one element and REQUIRE-MATCH is t, it can be quite redundant to go via the minibuffer. Would it make sense if in such a case completing-read could skip the minibuffer completely and simply return the car of COLLECTION? The specific situation that made me think about this was the command ibuffer-switch-to-saved-filter-groups when ibuffer-saved-filter-groups is a list with one element. Of course, the surrounding code could also shortcut the call of completing-read in such a case. But completing-read is possibly the better place to implement such a behavior, say via a particular value of REQUIRE-MATCH. In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1) of 2012-06-10 on regnitz Windowing system distributor `The X.Org Foundation', version 11.0.10706000 Configured using: `configure '--prefix=/home/winkler/emacs/24.1'' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-02 1:38 bug#12331: 24.1; completing-read when COLLECTION has exactly one element Roland Winkler @ 2012-09-02 2:49 ` Drew Adams 2012-09-02 16:25 ` Roland Winkler 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2012-09-02 2:49 UTC (permalink / raw) To: 'Roland Winkler', 12331 > If the arg COLLECTION of completing-read is a list with exactly one > element and REQUIRE-MATCH is t, it can be quite redundant to go via > the minibuffer. Would it make sense if in such a case > completing-read could skip the minibuffer completely and simply > return the car of COLLECTION? Hi Roland. `completing-read' offers possible candidates, but for lax completion it does not require you to choose any of them - you can enter anything you like. So this would make sense only for strict completion. Depending on the context, even for strict completion it might sometimes be surprising for a user not to see any prompt for completion. That is, if a user expects to choose and is not offered a choice, that can be surprising/confusing. Of course if for some given occurrence of `completing-read' in the code COLLECTION is *always* a singleton, then there will be no surprise. But in that case there is also presumably no reason to call `completing-read'. ;-) As you say, "the surrounding code could also shortcut the call of completing-read in such a case." That makes the most sense to me. It is, after all, the surrounding code that reflects the design intention and can tell what it might really mean in the current context to have only a singleton COLLECTION. "But completing-read is possibly the better place to implement such a behavior" I don't think so, for the above reasons. Why do you think so? "say via a particular value of REQUIRE-MATCH." In that case it is the surrounding code that is making the decision, as it should. That is better at least than systematically having *any* non-nil REQUIRE-MATCH mean that a singleton COLLECTION returns the sole candidate. What you suggest is then equivalent to this: (if (and COLLECTION (not (cdr COLLECTION))) (first-candidate COLLECTION) (completing-read ...)) where `first-candidate' returns the candidate corresponding to (car COLLECTION), doing the right thing for a list or string. Is it worth moving such logic into `completing-read', adding a particular non-nil value of REQUIRE-MATCH to implement it? I don't think so. FWIW, I use `completing-read' a lot, and I have never had a use for such treatment. Others might disagree... Why don't you try it for a while, and see if you really find it useful? [FWIW, in Icicles users can choose whether completion happens automatically whenever there is a sole matching candidate (which is more general than the cases where COLLECTION is a singleton). In that case, they need only hit RET, not TAB RET. (And they can configure a delay for the automatic completion, to give them time to change erroneous input, since this is about a sole match against their input.) But being prompted and hitting RET is still more interaction than what you are suggesting.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-02 2:49 ` Drew Adams @ 2012-09-02 16:25 ` Roland Winkler 2012-09-03 13:42 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Roland Winkler @ 2012-09-02 16:25 UTC (permalink / raw) To: Drew Adams; +Cc: 12331 On Sat Sep 1 2012 Drew Adams wrote: > > If the arg COLLECTION of completing-read is a list with exactly one > > element and REQUIRE-MATCH is t, it can be quite redundant to go via > > the minibuffer. Would it make sense if in such a case > > completing-read could skip the minibuffer completely and simply > > return the car of COLLECTION? > > `completing-read' offers possible candidates, but for lax > completion it does not require you to choose any of them - you can > enter anything you like. So this would make sense only for strict > completion. I only have in mind a situation where one has something like REQUIRE-MATCH being t, see above. In the particular context that triggered my report (i.e., the command ibuffer-switch-to-saved-filter-groups) COLLECTION is the user variable ibuffer-saved-filter-groups that defaults to nil. So any non-nil value is something where we may assume the user has chosen it deliberately. If nonethless we ask the user what he or she wants even though there is only one choice available, it much reminds of one of my least favorite operating systems. But maybe such a scenario is all in all not too common in the world of Emacs to justify a modification of completing-read. So if nobody else gets excited about my proposal (and nobody disagrees with the following either), I'll merely shortcut the call of completing-read in ibuffer-switch-to-saved-filter-groups if the list ibuffer-saved-filter-groups has just one element. Then I'll close this bug report. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-02 16:25 ` Roland Winkler @ 2012-09-03 13:42 ` Stefan Monnier 2012-09-03 16:26 ` Roland Winkler 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2012-09-03 13:42 UTC (permalink / raw) To: Roland Winkler; +Cc: 12331 > chosen it deliberately. If nonethless we ask the user what he or she > wants even though there is only one choice available, it much > reminds of one of my least favorite operating systems. The motivation sounds good, but the minibuffer prompt always offers one more choice, i.e. C-g. So accepting the only choice without prompting might end up being a bit too eager in some cases. > But maybe such a scenario is all in all not too common in the world > of Emacs to justify a modification of completing-read. I think so, yes. So I suggest you look for callers where that could be used, and if they are common enough, we could consider adding a special value of `require-match' which would allow such a short-circuiting. Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-03 13:42 ` Stefan Monnier @ 2012-09-03 16:26 ` Roland Winkler 2012-09-03 18:47 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Roland Winkler @ 2012-09-03 16:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: 12331 On Mon Sep 3 2012 Stefan Monnier wrote: > > chosen it deliberately. If nonethless we ask the user what he or she > > wants even though there is only one choice available, it much > > reminds of one of my least favorite operating systems. > > The motivation sounds good, but the minibuffer prompt always offers one > more choice, i.e. C-g. So accepting the only choice without prompting > might end up being a bit too eager in some cases. Sure, under any circumstances I would not want to make this a default for completing-read. I merely suggest that there are scenarios where shortcutting the invocation of the minibuffer can be reasonable. And I hope you don't mind we give this a try for the particular example of ibuffer-switch-to-saved-filter-groups described in my previous email. > I think so, yes. So I suggest you look for callers where that could be > used, and if they are common enough, we could consider adding a special > value of `require-match' which would allow such a short-circuiting. The least questionable examples are, in my opinion, those cases where the elements in the list COLLECTION reflect a choice the user made earlier (such as COLLECTION being a user variable defaulting to nil). I'll see whether I'll find more cases of that kind. Roland ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-03 16:26 ` Roland Winkler @ 2012-09-03 18:47 ` Stefan Monnier 2012-09-04 3:38 ` Stefan Monnier 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2012-09-03 18:47 UTC (permalink / raw) To: Roland Winkler; +Cc: 12331 > I merely suggest that there are scenarios where shortcutting the > invocation of the minibuffer can be reasonable. Yes, there's doubt it can be a good idea. > And I hope you don't mind we give this a try for the particular > example of ibuffer-switch-to-saved-filter-groups described in my > previous email. By all means, go for it. > The least questionable examples are, in my opinion, those cases where > the elements in the list COLLECTION reflect a choice the user made > earlier (such as COLLECTION being a user variable defaulting to nil). There are also all the cases where the consequences of the choice are all harmless (e.g. the command can easily be undone afterwards). Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-03 18:47 ` Stefan Monnier @ 2012-09-04 3:38 ` Stefan Monnier 2012-09-23 12:55 ` Roland Winkler 0 siblings, 1 reply; 8+ messages in thread From: Stefan Monnier @ 2012-09-04 3:38 UTC (permalink / raw) To: Roland Winkler; +Cc: 12331 >> I merely suggest that there are scenarios where shortcutting the >> invocation of the minibuffer can be reasonable. > Yes, there's doubt it can be a good idea. ^ no -- Stefan ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12331: 24.1; completing-read when COLLECTION has exactly one element 2012-09-04 3:38 ` Stefan Monnier @ 2012-09-23 12:55 ` Roland Winkler 0 siblings, 0 replies; 8+ messages in thread From: Roland Winkler @ 2012-09-23 12:55 UTC (permalink / raw) To: 12331-done Version: 24.3 2012-09-23 Roland Winkler <winkler@gnu.org> * ibuf-ext.el (ibuffer-switch-to-saved-filter-groups): If list ibuffer-saved-filter-groups has one element, shortcut the call of completing-read. (Bug#12331) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-09-23 12:55 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-02 1:38 bug#12331: 24.1; completing-read when COLLECTION has exactly one element Roland Winkler 2012-09-02 2:49 ` Drew Adams 2012-09-02 16:25 ` Roland Winkler 2012-09-03 13:42 ` Stefan Monnier 2012-09-03 16:26 ` Roland Winkler 2012-09-03 18:47 ` Stefan Monnier 2012-09-04 3:38 ` Stefan Monnier 2012-09-23 12:55 ` Roland Winkler
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.