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 19:23:12 -0700 (PDT) Message-ID: <7897022a-fea7-44cf-9781-8dd6a1da2f3e@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> <3d3bc85b-31d3-4701-8acd-45591d075253@default> <7c2b788f-8c34-4488-a3c2-223c94e876cb@default> <37139f10-a3de-f0f0-8453-67bedf78c7ec@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 1496283954 20587 195.159.176.226 (1 Jun 2017 02:25:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2017 02:25:54 +0000 (UTC) To: Dmitry Gutov , Ryan Thompson , 27158@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 01 04:25:49 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 1dGFo4-00054E-6V for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jun 2017 04:25:48 +0200 Original-Received: from localhost ([::1]:34935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGFo9-0006XS-M4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 31 May 2017 22:25:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGFmQ-0005fu-7Y for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 22:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGFmM-0006aU-8t for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 22:24:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45544) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGFmM-0006aQ-55 for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 22:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGFmL-0006d2-WC for bug-gnu-emacs@gnu.org; Wed, 31 May 2017 22:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Jun 2017 02:24: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.149628380825441 (code B ref 27158); Thu, 01 Jun 2017 02:24:01 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 02:23:28 +0000 Original-Received: from localhost ([127.0.0.1]:48221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGFlo-0006cG-AQ for submit@debbugs.gnu.org; Wed, 31 May 2017 22:23:28 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:44152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGFlm-0006c4-OS for 27158@debbugs.gnu.org; Wed, 31 May 2017 22:23:27 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v512NJEa026847 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 1 Jun 2017 02:23:20 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v512NHkR013803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 02:23:19 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v512NEkD030284; Thu, 1 Jun 2017 02:23:16 GMT In-Reply-To: <37139f10-a3de-f0f0-8453-67bedf78c7ec@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: aserv0022.oracle.com [141.146.126.234] 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:133123 Archived-At: > > The value of that variable is supposed to accept the same > > args as `completing-read'. Understood is that `completing-read' > > just passes its args along to the value of `completing-read-function'. >=20 > That will change. I certainly hope not, a priori. No good reason has been given for that. Just a trumpian pronouncement of a change to come. > > Anything else makes it impossible for `completing-read-function' > > to be as general as it should be. >=20 > (defun completing-read (prompt collection &optional predicate > require-match initial-input hist def > inherit-input-method) > (funcall completing-read-function > prompt collection predicate require-match > initial-input hist (or def "") inherit-input-method)) >=20 > should suffice. It doesn't suffice. This should suffice, as advertised: (funcall completing-read-function prompt collection predicate require-match initial-input hist def inherit-input-method) And in your `completing-read-function': (setq def (or def "")). End of story. It really seems like you are making a mountain out of a mole hill. You want DEF =3D nil to act like DEF =3D "". Big deal. Just do that in the right place: inside your `completing-read-function'. > > What prevents you from making `completing-read' behave that > > way (or any other way) within your context? Why is it > > insufficient for you to do that in your value of > > `completing-read-function' or by advising `completing-read' > > for the duration? >=20 > My context is "the whole of Emacs". That's what Ido Ubiquitous > is supposed to be affecting and improving. Really? Even when `ido-ubiquitous-mode' is off? What about users who do not want to use `ido-ubiquitous-mode'? Do they count too? Do you mean that all of Emacs will succumb to `ido-ubiquitous-mode'? Will you be expecting all Emacs users and libraries to adhere to the "improvement" of Ido Uber Alles? Not every user is an Ido user. `completing-read' does not belong to Ido - it is more general than the restricted behavior you've been pitching. Having nil DEF act like "" is a special case. If that behavior is contained within `ido-ubiquitous-mode' then that mode should already be able to impose whatever completion behavior it wants. Isn't that fair enough: Keep Ido Ubiquitous completion behavior for `ido-ubiquitous-mode', and not for all of Emacs and all the time? And it should be able to do that without changing anything in `completing-read' or `completing-read-function'. And if it does need to change the value of `completing-read-function' for the duration, it can do that. And if it needs to advise `completing-read' for the duration, it can do that. That seems clear enough. Your mode can use any kind of completion it wants. Again: What prevents you from making `completing-read' behave that way (or any other way) within your context? Why is it insufficient for you to do that in your value of `completing-read-function' or by advising `completing-read' for the duration? No answer. Just a statement that your context is the World Of Emacs, that you "will change" the behavior not just for Ido Ubiquitous but for all of Emacs. Sheesh. Please do whatever you need to do to `completing-read' inside the mode only. That's why it's a mode. That's why it's called `ido-ubiquitous-mode' and not "Emacs". I change the behavior of `completing-read' considerably more than what you've described, but I do it only inside `icicle-mode'. When the mode is off, the vanilla behavior returns to `completing-read'. Not a big deal. Normal. Icicles completion too applies to "the whole of Emacs". That's what Icicles "affects and improves". And it does so only when Icicle mode is on. I don't see why `ido-ubiquitous-mode' can't act similarly. What's so special about it, that it needs to not only modify `completing-read' behavior when the mode is on but modify more generally, for all uses, regardless of whether `ido-ubiquitous-mode' is on?