GNU bug report logs - #12331
24.1; completing-read when COLLECTION has exactly one element

Previous Next

Full log

View this message in rfc822 format

From: "Roland Winkler" <winkler <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 12331 <at> debbugs.gnu.org
Subject: bug#12331: 24.1; completing-read when COLLECTION has exactly one element
Date: Sun, 2 Sep 2012 11:25:29 -0500

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.