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#27193: 25.2; tmm should use completing-read-default Date: Fri, 2 Jun 2017 15:19:40 -0700 (PDT) Message-ID: <236c968a-a11f-4a5a-88bc-f60edb50aa18@default> References: <7241c3bc-d7eb-4ce3-998e-dcc21d54ef7f@default> <6a2811d5-8a21-47a6-b416-41bda3e36f67@default> <669d7dff-a4bf-75b2-1652-6217efb84c72@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 1496442011 15306 195.159.176.226 (2 Jun 2017 22:20:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2017 22:20:11 +0000 (UTC) To: Dmitry Gutov , Ryan Thompson , 27193@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 03 00:20:08 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 1dGuvP-0003jE-L7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jun 2017 00:20:07 +0200 Original-Received: from localhost ([::1]:51648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGuvU-0005jA-UR for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 18:20:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGuvP-0005hd-8B for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:20:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGuvK-0001fU-Ar for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49348) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGuvK-0001fL-7Q for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGuvJ-000298-Vl for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 18: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: Fri, 02 Jun 2017 22:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27193 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27193-submit@debbugs.gnu.org id=B27193.14964419958231 (code B ref 27193); Fri, 02 Jun 2017 22:20:01 +0000 Original-Received: (at 27193) by debbugs.gnu.org; 2 Jun 2017 22:19:55 +0000 Original-Received: from localhost ([127.0.0.1]:52024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuvD-00028g-KD for submit@debbugs.gnu.org; Fri, 02 Jun 2017 18:19:55 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:30754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGuvA-00028R-H2 for 27193@debbugs.gnu.org; Fri, 02 Jun 2017 18:19:52 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v52MJgZZ025987 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 22:19:43 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v52MJgZE022904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jun 2017 22:19:42 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v52MJf85028616; Fri, 2 Jun 2017 22:19:41 GMT In-Reply-To: <669d7dff-a4bf-75b2-1652-6217efb84c72@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: userv0022.oracle.com [156.151.31.74] 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:133181 Archived-At: > > The case that needs to be made for your proposal is really (IMO) that > > there are /NO/ values of `completing-read-function', apart from > > `completing-read-default', which would be compatible with the tmm code. >=20 > That would be too strong. No. That's exactly what you're forcing, if you force `completing-read-default' as the ONLY possible value. Precisely that: you allow no other values. The claim behind that must be that ALL other values would be problematic and so must be disallowed. > > I don't think you can make that case. I sense you > > are extrapolating from your own particular use of > > `completing-read-function' (and similar uses). >=20 > This is ridiculous. If there are functions that adhere to the contract > of completing-read-function, and tmm can't work with them, tmm should > use completing-read-default, and that's that. "Adhere to the contract of `completing-read-function'"? Are you kidding? What contract is that? (defvar completing-read-function 'completing-read-default "The function called by `completing-read' to do its work. It should accept the same arguments as `completing-read'.") Just accept the arguments - that's the only contract. "Do the work" of `completing-read' is completely vague. That means that anytime you can come up with a function that accepts those args and causes trouble, `completing-read-default' should be imposed as the only possible value. THAT is ridiculous. > I'll install the submitted patch in a few days if someone=20 > doesn't beat me to it. Of course you will. > > The result is not even recognizable as completing-read. > > > > I don't think so. Certainly no more unrecognizable than Ido... >=20 > You are mixing up concepts right and left. E.g. APIs with their callers. Nonsense. Ido's completion behavior is as far from that of vanilla `completing-read' as is Tmm's completion behavior ("the result").