From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12331: 24.1; completing-read when COLLECTION has exactly one element Date: Sat, 1 Sep 2012 19:49:58 -0700 Message-ID: References: <87k3wdqk4w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1346554244 17319 80.91.229.3 (2 Sep 2012 02:50:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2012 02:50:44 +0000 (UTC) To: "'Roland Winkler'" , <12331@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 02 04:50:46 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T80Gq-00075n-Iy for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Sep 2012 04:50:44 +0200 Original-Received: from localhost ([::1]:41827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T80Go-0002Ay-3l for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Sep 2012 22:50:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T80Gl-0002Ap-3T for bug-gnu-emacs@gnu.org; Sat, 01 Sep 2012 22:50:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T80Gk-00066R-18 for bug-gnu-emacs@gnu.org; Sat, 01 Sep 2012 22:50:39 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52274) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T80Gj-00066N-Tv for bug-gnu-emacs@gnu.org; Sat, 01 Sep 2012 22:50:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T80I5-0000Ko-Vi for bug-gnu-emacs@gnu.org; Sat, 01 Sep 2012 22:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Sep 2012 02:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12331 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12331-submit@debbugs.gnu.org id=B12331.13465542971255 (code B ref 12331); Sun, 02 Sep 2012 02:52:01 +0000 Original-Received: (at 12331) by debbugs.gnu.org; 2 Sep 2012 02:51:37 +0000 Original-Received: from localhost ([127.0.0.1]:33587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T80Hh-0000KB-C0 for submit@debbugs.gnu.org; Sat, 01 Sep 2012 22:51:37 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:16994) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T80Hf-0000K5-SE for 12331@debbugs.gnu.org; Sat, 01 Sep 2012 22:51:36 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q822o8f9008169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 2 Sep 2012 02:50:09 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q822o7JG019485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2012 02:50:08 GMT Original-Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q822o7Rd023027; Sat, 1 Sep 2012 21:50:07 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 01 Sep 2012 19:50:07 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87k3wdqk4w.fsf@gnu.org> Thread-Index: Ac2Iq7KNB274fyuvSuyrTWs7oo/qCAAALeSQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63666 Archived-At: > 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.]