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: Wed, 31 May 2017 08:19:10 -0700 (PDT) Message-ID: <3d3bc85b-31d3-4701-8acd-45591d075253@default> References: <24f4a025-ad7b-06e5-10ee-f122bef32402@thompsonclan.org> <0276a0cd-874b-47ee-a2dc-fe8ca08ece9d@default> <21029018-5890-e545-8b50-ee856bc2caec@yandex.ru> <562784bd-e22b-411d-8230-4f95fe2fa7db@default> <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> 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 1496244017 25781 195.159.176.226 (31 May 2017 15:20:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 May 2017 15:20:17 +0000 (UTC) To: Dmitry Gutov , Ryan , 27158@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 31 17:20:13 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 1dG5Px-0006Vb-M3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 17:20:13 +0200 Original-Received: from localhost ([::1]:60154 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dG5Q2-00067j-SJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 11:20:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dG5Pr-00065T-WA for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 11:20:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dG5Pm-0000gI-7e for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 11:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dG5Pm-0000g0-3r for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 11:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dG5Pl-0003hH-V1 for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 11:20: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 15:20: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.149624396114161 (code B ref 27158); Wed, 31 May 2017 15:20:01 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 31 May 2017 15:19:21 +0000 Original-Received: from localhost ([127.0.0.1]:47600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5P7-0003gL-Gm for submit@debbugs.gnu.org; Wed, 31 May 2017 11:19:21 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dG5P5-0003g7-MR for 27158@debbugs.gnu.org; Wed, 31 May 2017 11:19:20 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4VFJCwr029155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 15:19:13 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v4VFJCxu013536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 31 May 2017 15:19:12 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v4VFJBhh028291; Wed, 31 May 2017 15:19:12 GMT In-Reply-To: <4dfcd02b-53bc-c430-89db-f93ad6b283c2@yandex.ru> 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:133091 Archived-At: > I mean that having the default argument when it's not specified, is > not necessary. There is no need for "default default". >=20 > > Just because some callers might not need it does not mean that > > it is not useful for other callers. >=20 > They can use the DEFAULT argument. So are you arguing that DEFAULT should be a mandatory argument? I addressed that in my first message. > >> Prohibit them from finishing completion, except through entering > >> a valid value, or pressing C-g. > > > > (while ) > > > > Is that hard? >=20 > It makes completing-read-function calling convention > more complex for no real gain. So you do think that it is hard? Hard to believe. And how so, no real gain? If there is no real gain for you then don't do it. You said you wanted to keep prompting and getting input as long as the user tried to exit with no input. Now you are saying that doing that would e no real gain. (?) > The simpler the API is, the easier it is to provide > alternative implementations for. By that logic we should get rid of most of the optional args to `completing-read'. Or maybe we should get rid of `completing-read' and let people do it all using `read-from-minibuffer'? But go ahead. Make DEFAULT mandatory if you like. See how that change goes down. But if an explicit DEFAULT arg is the solution then your completion system need only set arg DEFAULT to "" when it is nil, no? Or set it to the first completion candidate when it is nil or "". Or ... . > And also, we will have new callers who are not aware of this quirk. > Those packages might fail to account for the possibility that > completing-read can return "". After all, they passed t as the > REQUIRE-MATCH argument. >=20 > > What happens when you set `completing-read-function' to your > > `my-completing-read'? >=20 > Some callers rely on it returning an empty string when the user > presses RET. Imagine that. And they would rely on the same thing if they passed "" as an explicit DEFAULT arg. > In those cases, if my-completing-read does not provide this > ability (literally, does not return "" when the user presses > RET right away), the user experience can suffer. Indeed. So don't do that. Respect what the caller expects. > And some UIs make it non-trivial for the > completing-read-function to behave like above. E.g. add > "" to the completions list but only when the user does > not type anything. If you cannot test for "" return value then checking for no input becomes even harder. Sure, explicit "" DEFAULT provides the same possibility for checking for input. What does your `completing-read-function' want to do in that case? Sorry, but it's not clear to me what the problem is. Anything I think I see you saying about the problem does not seem to be solved by making DEFAULT mandatory. What am I missing? How about a concrete example?