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: Thu, 1 Jun 2017 07:57:26 -0700 (PDT) Message-ID: 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> <7897022a-fea7-44cf-9781-8dd6a1da2f3e@default> 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 1496329094 5703 195.159.176.226 (1 Jun 2017 14:58:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Jun 2017 14:58:14 +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 16:58:10 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 1dGRY9-0001Kr-UX for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jun 2017 16:58:10 +0200 Original-Received: from localhost ([::1]:45095 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGRYF-0001z7-54 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Jun 2017 10:58:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGRY5-0001xL-Rr for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 10:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGRY2-0006PQ-Kw for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 10:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGRY2-0006PK-HI for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 10:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGRY2-0006T8-7d for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 10:58: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 14:58:02 +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.149632905924832 (code B ref 27158); Thu, 01 Jun 2017 14:58:02 +0000 Original-Received: (at 27158) by debbugs.gnu.org; 1 Jun 2017 14:57:39 +0000 Original-Received: from localhost ([127.0.0.1]:49831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGRXe-0006SS-L1 for submit@debbugs.gnu.org; Thu, 01 Jun 2017 10:57:38 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:36550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGRXd-0006SE-Bb for 27158@debbugs.gnu.org; Thu, 01 Jun 2017 10:57:37 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v51EvTtO012003 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 14:57:30 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v51EvTB4000585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jun 2017 14:57:29 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v51EvRet024919; Thu, 1 Jun 2017 14:57:28 GMT In-Reply-To: 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: aserv0021.oracle.com [141.146.126.233] 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:133135 Archived-At: > >> (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)) > >> should suffice. > > > > It doesn't suffice. >=20 > Citation needed. No "citation" needed. `completing-read-function' needs to have the same signature as `completing-read'. I am the one who requested `completing-read-function' and pushed to have it added to Emacs. Its purpose is to easily let you change the _complete_ behavior of `completing-read', just by binding a variable. That requires passing it exactly the same arguments, to do as it pleases with them. If, as in your case, it wants to act as if DEF were in fact `(or DEF "")', it can do that. If you want to simulate an explicit DEF when none is present, that's easy enough to do in the function that is your value of `completing-read-function'. You don't need to force that on all uses of `completing-read-function'. Changing the signature of `completing-read-function' in the way you suggest makes all uses of `completing-read-function' follow the path you've outlined for `ido-ubiquitous-mode'. That's a particular kind of completion. No thanks. And no need. You don't need that, to make your mode do what you want. If you disagree, please show da codez: a simple example that doesn't work and for which you see no possible solution. > >> 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? >=20 > Obviously not. Also not when it's not installed, in case you > were wondering. In that case, it's obvious that you can do whatever you need inside the mode. Do your (setq def (or def "")) there, for use only by your mode. You haven't shown why you think you cannot do that. > > 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. >=20 > You fail at reading. Nonsense. Why can't you use `completing-read-function' to do what you want in your mode? > > 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. >=20 > And yet, you haven't contributed anything helpful to this > discussion so far. Ooooh. Please say why you cannot do what you need for just your mode. `completing-read' is not intended to have only the behavior you want. But it is designed to _let you get_ the behavior you want, as well as other behaviors. There is a reason for the DEF argument, a reason for it to be optional, and a reason for its default value to be "". All of which I've gone over. This thread was started by a misconception of what DEF is for, thinking that it is useless. It may be useless - or even an obstacle to be worked around - for your use case, but it is not useless for Emacs. DEF was even expanded several releases ago, to allow a value that is a list of default values. Those too likely don't fit your narrow use case. Default values are intentionally not completion candidates. And yes, in general they are useful, even if not for your use case of `completing-read'. If your use case calls for no default values, or in effect wants to treat them as completion candidates, it's easy enough for you to do that. That is not the general, default, intentional treatment of DEF by `completing-read'.