From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Questions about the `completing-read-function' interface Date: Fri, 17 Apr 2015 07:10:18 -0700 (PDT) Message-ID: <947804d6-1810-4b0c-a520-758103c84972@default> References: <87lhhrxeg2.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1429279848 16211 80.91.229.3 (17 Apr 2015 14:10:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 14:10:48 +0000 (UTC) To: Oleh Krehel , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 17 16:10:35 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yj6yX-0006AJ-ML for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 16:10:33 +0200 Original-Received: from localhost ([::1]:41585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj6yX-0001Mv-34 for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 10:10:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj6yT-0001Mp-8Z for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:10:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj6yQ-0006CK-H7 for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:10:29 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj6yQ-0006Bn-AU for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:10:26 -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 t3HEAJf1027039 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Apr 2015 14:10:20 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3HEAJ43029851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Apr 2015 14:10:19 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t3HEAJLh031459; Fri, 17 Apr 2015 14:10:19 GMT In-Reply-To: <87lhhrxeg2.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185523 Archived-At: > I'd like to know, if a function calls `completing-read', should the > members of DEF be inside COLLECTION? I haven't found info on this in the > doc, and `completing-read-default' doesn't seem to handle DEF not being > in COLLECTION. Completion can be lax: user input need not match any of the completion candidates (null REQUIRE-MATCH argument). Whether DEF is one of the candidates is generally irrelevant in this case. And COLLECTION can be a function, returning any string it wants. It can even return a value that cannot be known at coding time. What applies to user input pretty much applies to what DEF can be. So in the general case no, DEF need not be one of the candidates (or a subset of them, if it is a list). The calling function (context) knows whether DEF should be one of the candidates. And only the calling function. > But, for instance, `magit-completing-read' (and some other functions) do > make that assumption. Then they need to prepare for that assumption. They have a particular requirement for the relation between COLLECTION and DEF, and they need to manage that use case. > And `helm-mode' has code to deal with that. I'm thinking of adding a > similar work-around to `ivy-mode' as well, but maybe it would be better > if it was somehow mandated that DEF should be in COLLECTION. Because, > theoretically, DEF can be a list, and it would be inefficient for the > completion engine to go through the whole collection just to make sure > that DEF isn't there, and then add it there. Please don't. Any given *caller* of `completing-read' that needs to rely on DEF being a member (or a subset) of COLLECTION can just DTRT. > As second question is about this interface: > (setq completing-read-function 'foo) >=20 > We've accumulated a bunch of packages that call this: icomplete-mode, > helm-mode, icy-mode, ivy-mode. (Not `icy-mode', FWIW. But it does use `read-file-name-function'.) > If these functions are called in succession, each of them will think > that they are on, however, the resource (`completing-read-function') > will belong only to the last one. > Maybe we could have this type of interface: > (set-completing-read-function 'foo callback) >=20 > So that each time `set-completing-read-function' is called, the current > minor mode is properly shut down in the callback. We could keep the > current interface for single-use completion through a let binding. But > all the minor modes mentioned would use `set-completing-read-function'. Again, please do not try to hard-wire any such behavior. Leave it up to the various libraries or other callers of `completing-read' to handle any such possible interactions, if they see the need. What I hear so far sounds like solutions in search of problems. Or perhaps a case of the X-Y problem. Instead of talking solutions, perhaps you can present the real problem you are looking at - what is it that you are trying to do?