bug#12331: 24.1; completing-read when COLLECTION has exactly one element

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Roland Winkler]

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''

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Drew Adams]

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

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Roland Winkler]

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.

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Stefan Monnier]

> 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

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Roland Winkler]

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

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Stefan Monnier]

> 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

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Stefan Monnier]

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

bug#12331: 24.1; completing-read when COLLECTION has exactly one element

[Roland Winkler]

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)