From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: completion discrepancy between default completion and helm/ivy completions Date: Mon, 14 Nov 2016 09:20:29 -0500 Message-ID: References: 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 1479133315 22347 195.159.176.226 (14 Nov 2016 14:21:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 14:21:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Schmitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 14 15:21:51 2016 Return-path: Envelope-to: ged-emacs-devel@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 1c6I8V-0002tO-W4 for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 15:21:28 +0100 Original-Received: from localhost ([::1]:40354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6I8Y-0004zE-Tu for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 09:21:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6I7g-0004yO-BH for emacs-devel@gnu.org; Mon, 14 Nov 2016 09:20:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6I7c-0004OC-6l for emacs-devel@gnu.org; Mon, 14 Nov 2016 09:20:36 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:7986) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6I7c-0004Nf-0T for emacs-devel@gnu.org; Mon, 14 Nov 2016 09:20:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBgALW9BX/7XLSC1dHAEBBAEBgy0BAQEBAR6ETYVQr3aCA4YWBAICgWk7EgECAQEBAQEBAV4nhGIBAQMBIzMjBQsLGgIYDgICFBgNJIhVCLA1jCABAQgCJYEFiXiHQoJaBY8dijyZDYYLkEslAi2Ebh6GCgEBAQ X-IPAS-Result: A0CWBgALW9BX/7XLSC1dHAEBBAEBgy0BAQEBAR6ETYVQr3aCA4YWBAICgWk7EgECAQEBAQEBAV4nhGIBAQMBIzMjBQsLGgIYDgICFBgNJIhVCLA1jCABAQgCJYEFiXiHQoJaBY8dijyZDYYLkEslAi2Ebh6GCgEBAQ X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="279263917" Original-Received: from 45-72-203-181.cpe.teksavvy.com (HELO pastel.home) ([45.72.203.181]) by smtp.teksavvy.com with ESMTP; 14 Nov 2016 09:20:29 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id BBB3C64B73; Mon, 14 Nov 2016 09:20:29 -0500 (EST) In-Reply-To: (Alan Schmitt's message of "Mon, 14 Nov 2016 14:22:54 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209383 Archived-At: > (when (and org-contacts-enable-completion > (boundp 'completion-at-point-functions)) > (add-hook 'message-mode-hook 'org-contacts-setup-completion-at-point)) > which does > (defun org-contacts-setup-completion-at-point () > "Add `org-contacts-message-complete-function' as a new function > to complete the thing at point." > (add-to-list 'completion-at-point-functions > 'org-contacts-message-complete-function)) [ Side point: `add-to-list` is wrong, it should be `add-hook` (tho with additional "nil 'local" arguments, to only add to the buffer-local part of the hook). ] > That function basically checks if this is a place where completion > should happen (To field, for instance), then calls all the > org-contacts-complete-functions until one succeeds. One such function is > org-contacts-complete-group that, in some case, returns a function > taking unused arguments and returning the completion as a string. To > summarize, is it okay for a function in completion-at-point-functions to > return such a function? The docstring of `completion-at-point-functions` says: Each function on this hook is called in turn without any argument and should return either nil, meaning it is not applicable at point, or a function of no arguments to perform completion (discouraged), or a list of the form (START END COLLECTION . PROPS), where: [...] So, yes, it's acceptable (tho discouraged) to return a function, but this function should then *perform the completion* (rather than just return a string). > I guess I should try to return something of the form (start end > collection . props) instead, with collection being a singleton=E2=80=A6 Why a singleton? The driving design should be: return a `collection` which is valid for any text between `start` and `end`. Because `collection` will be matched against the text between `start` and `end` anyway (and the UI may decide to match it against other text as well, e.g. to provide other completion styles than just prefix completion). Stefan