From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#27158: 25.2; Eliminating old usage of completing-read from built-in files Date: Tue, 30 May 2017 22:52:16 -0700 (PDT) Message-ID: <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1496209993 4139 195.159.176.226 (31 May 2017 05:53:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 May 2017 05:53:13 +0000 (UTC) To: Ryan , 27158@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 31 07:53:06 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFwZ8-0000le-69 for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 07:53:06 +0200 Original-Received: from localhost ([::1]:57402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFwZD-0004CI-FL for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 01:53:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFwZ7-0004C2-85 for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 01:53:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFwZ4-00056k-5b for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 01:53:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43388) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dFwZ4-00056c-1t for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 01:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dFwZ3-0008HK-Kj for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 01:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 31 May 2017 05:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27158 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27158-submit@debbugs.gnu.org id=B27158.149620995031785 (code B ref 27158); Wed, 31 May 2017 05:53:01 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 31 May 2017 05:52:30 +0000 Original-Received: from localhost ([127.0.0.1]:46065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFwYY-0008Ga-4q for submit@debbugs.gnu.org; Wed, 31 May 2017 01:52:30 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:49060) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFwYV-0008GM-Uy for 27158@debbugs.gnu.org; Wed, 31 May 2017 01:52:28 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4V5qJv9003077 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 05:52:20 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4V5qJmT000389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 05:52:19 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4V5qIFW031622; Wed, 31 May 2017 05:52:18 GMT In-Reply-To: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:133075 Archived-At: > completing-read-default still supports a behavior that is, as > far as I know, a legacy feature that is kept only for backward=20 > compatibility with code that was written before the default > argument was added: The default arg has been available since the beginning, AFAIK. The behavior you describe is no more legacy than is providing a default-value arg. Nothing to do with backward compatibility, I think. > if the input is empty and the user presses RET, it will return > the empty string, even if require-match is non-nil and the empty > string is not in the collection. And it returns the default, even if REQUIRE-MATCH is non-nil and the default is not in the collection. Do you dislike that behavior too? "" is just the default default, if you like (or not). Would you make a default arg be mandatory instead of optional? Is that it? If not, what default default would you propose? What should be returned if no explicit default is provided and the user hits RET with no input? "" seems like a great choice for the default default, to me. It's pretty much guaranteed never to coincide with any usable completion candidate (which is not the case for a non-empty default value). For one thing, that lets you easily check whether the user chose one of the candidates, even in the case where the collection is complex (e.g. a function). > This quirk Why is it a quirk? IN any case, nothing stops someone from defining their own `my-completing-read', which does not have this feature, er, quirk. I don't see the problem. > is a thorn in the side of packages that provide alternative > completing-read functions such as ido-ubiquitous an > ivy-mode, which both want to have RET return either the > default or the first choice on the list, not the empty string. They can do exactly do that - just by providing that as the default arg. RET with no input returns the default already. If you want to return the first candidate by default then just pass that candidate as the default arg. What am I missing? I also don't see the behavior as a thorn in the side of all packages that provide alternative kinds of completion. But you don't really say what you mean by a thorn, here. And I don't see it as a thorn in the side of other uses of `completing-read'. `completing-read' is a quite general function. Just because some particular user or package might not use it in every way possible is not a reason why its behavior should be limited to what some package uses. Nothing prevents a package from always supplying a default arg other than "". The doc string says: If the input is null, =E2=80=98completing-read=E2=80=99 returns DEF, or th= e first element of the list of default values, or an empty string if DEF is nil, regardless of the value of REQUIRE-MATCH. That's the design. What part of it do you not like, and why? What's the thorn/quirk? Sorry, but I don't see what problem you are trying to solve. Is it the need to specify a default other than "" when you don't want that default default? > While this behavior can probably not be changed without > breaking backward compatibility, Yes. > we can at least eliminate every use of the feature in the > elisp files included with Emacs. Why would we do that? It's up to calling code to decide what behavior it wants for RET with no input. Yes, probably there are some cases in existing code where a better default value might be provided. That's something to be looked at case by case. So far, I don't see a general problem to be fixed. Where's the bug?