From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Schmitt Newsgroups: gmane.emacs.devel Subject: Re: completion discrepancy between default completion and helm/ivy completions Date: Mon, 14 Nov 2016 14:22:54 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1479129839 29789 195.159.176.226 (14 Nov 2016 13:23:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2016 13:23:59 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 14 14:23:52 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 1c6HEa-0005Sj-6Q for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 14:23:40 +0100 Original-Received: from localhost ([::1]:40110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6HEd-0002zG-2O for ged-emacs-devel@m.gmane.org; Mon, 14 Nov 2016 08:23:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6HDz-0002z9-HL for emacs-devel@gnu.org; Mon, 14 Nov 2016 08:23:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6HDu-0000Xu-Cv for emacs-devel@gnu.org; Mon, 14 Nov 2016 08:23:03 -0500 Original-Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:23946) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c6HDu-0000X3-2L for emacs-devel@gnu.org; Mon, 14 Nov 2016 08:22:58 -0500 X-IronPort-AV: E=Sophos;i="5.31,638,1473112800"; d="asc'?scan'208";a="244896160" Original-Received: from cbg35-2-78-242-14-140.fbx.proxad.net (HELO top.local) ([78.242.14.140]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 14 Nov 2016 14:22:55 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 13 Nov 2016 10:38:35 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.134.164.83 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:209381 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2016-11-13 10:38, Stefan Monnier writes: >> Is it correct to register as a completion something that returns a >> string? > > I don't understand the question: register where? return a string in > which case? Thank you for bearing with me, here are the details. org-contacts adds completions hooks to message mode: (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)) 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 seems to say it's OK (except the function returned should not have any argument), but discouraged. I guess I should try to return something of the form (start end collection . props) instead, with collection being a singleton=E2=80=A6 >> Because it is what org-contacts does, but although it works with >> the default completion code, it breaks ivy or helm style completions. > > AFAIK those frameworks probably don't handle well completion tables > which use completion-boundaries, so I'd lean towards saying it's a bug > or a known limitation of those frameworks. But I haven't looked at them > in a long while, so maybe this isn't true any more. Thank you for your help, I'm starting to understand what is going on. I'll keep digging. Best, Alan =2D-=20 OpenPGP Key ID : 040D0A3B4ED2E5C7 Monthly Athmospheric CO=E2=82=82, Mauna Loa Obs. 2016-10: 401.57, 2015-10: = 398.29 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYKbqvAAoJEAQNCjtO0uXHL8QIAJepcZA5MQAbjssZJ3yDre+s IeshrfPEF85+IbUH9Gjv9Z/r2NM0blO9gE3KMs1OlEqQRhYTz4RZkaXczLxG+ELd ekmr0ddxNoOYZHcdcqqv7T/qeOaHnaodvP21bzxJQZzjzCjtALnLpqPws4+9wd+C qUg6gzGUSf+ZUuigBy/NmkCS6jnY6/520q2aNYfime8Mm+rIR/oVyLpGF6nwoOpY DtJ2OQ6ckpY1uevWbkPCitK9QOWs7wqr1jUw+WmZU5pc4tnrW7aVmv3G1iGL2Edm WgSCqXIUooaw3MmgCYWWrGM/760RRGntZILmJH8J8vvdW+kt5f+0CiJsnYsdWUw= =1CYU -----END PGP SIGNATURE----- --=-=-=--