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