From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: Questions about the `completing-read-function' interface Date: Fri, 17 Apr 2015 16:32:22 +0200 Message-ID: <87383yomfd.fsf@gmail.com> References: <87lhhrxeg2.fsf@gmail.com> <947804d6-1810-4b0c-a520-758103c84972@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429281506 13687 80.91.229.3 (17 Apr 2015 14:38:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Apr 2015 14:38:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 17 16:38:26 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 1Yj7PV-0007iM-8t for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 16:38:25 +0200 Original-Received: from localhost ([::1]:41792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj7PU-0008RF-OH for ged-emacs-devel@m.gmane.org; Fri, 17 Apr 2015 10:38:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj7PD-00086q-VW for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:38:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj7P5-0000LR-1L for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:38:07 -0400 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:33835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj7P4-0000Kc-QK for emacs-devel@gnu.org; Fri, 17 Apr 2015 10:37:58 -0400 Original-Received: by widjs5 with SMTP id js5so35392438wid.1 for ; Fri, 17 Apr 2015 07:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=AatCUhNmPfzmk/3kbunoLsB+9CTufPBDKVA3ama0DAY=; b=yr/ijqb0fDX+CzI69Bl5kfoUmqApqNZq7EzapeWENcyVPlkYvUr0hN1x+SCkqde/fz wNyGT+5jnh/gOZiYj9bwR3CrzzCIi5T77WLZEnHGYWsyreqMU7S96U25g2DAnS2L3dfM Q0/jfgO7MSDP0jjgelgIDBsFNDCn6MgNqeef4CwxvKrl05LH9PtjrWj3gMA/DIsgaMck BRwZ10SHwovy+yt9BI7XR+ew/pq3w2x51gFFLJXC+V4/TXk+19eyHWqTDncxnCDFbQug VAbkTc4BPadtRZzWES5gQuzmJMOIAp+UhB8fyrDyGWWghUr7FT+1RbQsmrluvQOXAOZX dYFw== X-Received: by 10.194.222.135 with SMTP id qm7mr6875504wjc.14.1429281473672; Fri, 17 Apr 2015 07:37:53 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id go4sm2944747wib.1.2015.04.17.07.37.53 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 17 Apr 2015 07:37:53 -0700 (PDT) In-Reply-To: <947804d6-1810-4b0c-a520-758103c84972@default> (Drew Adams's message of "Fri, 17 Apr 2015 07:10:18 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::231 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:185525 Archived-At: Drew Adams writes: >> 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. That's kind of what I'm saying. The calling function knows all the candidates, excepting the REQUIRE-MATCH case, yet it still sends the candidates in two batches: COLLECTION and DEF. >> 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. I don't get this statement. >> 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. I said nothing of hard-wiring. I just described an interface to which diverse packages can subscribe in order to get a benefit. If they don't want to do it, it's it's only an opportunity lost for them. I've seen the more generic packages playing around so many things that could be happening on the system. Could the system not give some facilities to manage the contested resources? Oleh