From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: Completing with anything Date: Mon, 21 Mar 2011 12:23:09 +0100 Message-ID: References: <87r5bhysp6.fsf@keller.adm.naquadah.org> <878vxovsym.fsf@keller.adm.naquadah.org> <87k4h7ua23.fsf@member.fsf.org> <87vd0romky.fsf@keller.adm.naquadah.org> <87mxm2na63.fsf@member.fsf.org> <87vd0qfhu3.fsf@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1300706613 10054 80.91.229.12 (21 Mar 2011 11:23:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2011 11:23:33 +0000 (UTC) Cc: Tassilo Horn , emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 12:23:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q1dCo-0003ix-2C for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 12:23:26 +0100 Original-Received: from localhost ([127.0.0.1]:37696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1dCm-0008Fv-Qo for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 07:23:24 -0400 Original-Received: from [140.186.70.92] (port=50669 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1dCd-00088O-UZ for emacs-devel@gnu.org; Mon, 21 Mar 2011 07:23:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1dCc-0002pv-5j for emacs-devel@gnu.org; Mon, 21 Mar 2011 07:23:15 -0400 Original-Received: from prometheus.naquadah.org ([212.85.154.174]:56976 helo=mx1.naquadah.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1dCb-0002pc-Tl; Mon, 21 Mar 2011 07:23:14 -0400 Original-Received: from cigue.easter-eggs.fr (coquelicot-a.easter-eggs.com [82.235.59.105]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.naquadah.org (Postfix) with ESMTPSA id D8C605C202; Mon, 21 Mar 2011 12:23:10 +0100 (CET) Mail-Followup-To: Stefan Monnier , Tassilo Horn , emacs-orgmode@gnu.org, emacs-devel@gnu.org In-Reply-To: (Stefan Monnier's message of "Fri, 18 Mar 2011 14:16:38 -0400") User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 212.85.154.174 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137465 gmane.emacs.orgmode:39869 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 18 2011, Stefan Monnier wrote: > There's a misunderstanding: AFAIK the patch sent by Tassilo does not > make the completion-at-point-function return a "function that performs > completion" but does properly return completion data (i.e. region start, > region end, and completion table), part of which happens to be > represented by a function. > I.e. this is not one of the discouraged cases. You're right, indeed! But I do not see anywhere the fact that the completion collection can be a function. I only found the sentence: "It would be consistent and clean for completion functions to allow lambda expressions (lists that are functions) as well as function symbols as COLLECTION, but this is impossible." in (elisp) Programmed Completion. Not sure it's really related to completion-at-point-functions, but well, it's not making things clearer for me anyhow. >> - Make completing code allows to replace the region being completed with >> somethig that does not match at all. > > AFAIK that's already the case, tho it depends on lots of factors, such > as what you mean by "completing code". I meant the code in minibuffer.el To be clear, the things that disturbs me is that this simple test case does not work as I would like it to: #+begin_src emacs-lisp (defun jd:completion-at-point-test () (list (point-at-bol) (point) '("Steve" "John"))) (add-to-list 'completion-at-point-functions 'jd:completion-at-point-test) #+end_src If you run that code into a buffer, and then type in this same buffer: L And try to complete that "L" with M-x completion-at-point, it will say "No match." But if you do: #+begin_src emacs-lisp (defun jd:completion-at-point-test () (list (point-at-bol) (point) '("Lionel" "Steve" "John"))) (add-to-list 'completion-at-point-functions 'jd:completion-at-point-test) #+end_src And try to complete a "L", it will complete to Lionel. Just because completion-at-point is trying to be smarter than my function, re-guessing which items from the collection are good candidates. Something my function already does (well, not in this example, but in real life). This is why I'm (kindly) finger pointing the "completing code in minibuffer.el", but I might be wrong (and hope to be! :-)). =2D-=20 Julien Danjou =E2=9D=B1 http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNhzUeAAoJEGEbqVCLeKXCLgkP/0Xmx7ccL6ccaJpMN51uybs3 M00M93gGFR4QlEldsnvWD+lm4qco7K+3QJCm7+OJq+ZgcNNMglmsd5priNKuQdvA VOrB1xkJYdOVEdvtAbYDuZocG3b5fuYvcSJzOHK44TLM0cxx5DD82BA0rJI2vLR2 yF7zTUPsGoK2/kV9A6PnzA/R4EMYVwjQs4MTYhp9gc6Q/bg8ccB9PmnniMqeQhsf 7HTgiaLEJ1sg5d4jFx6C/IfDTExe0WxpubAJ2HHx5mHVNbZHYhHNF57Vd4xiKIJp sNQdNr+UCvMPw+pd+pmIrOZb+5IBgT7uUC/vvugKXE1cE/NIcWQzqqwotlSzDBet RYJfi5J9NdUOiPKe8g8nrQkH5axRMfmugc3HpTOrnX2vbUwApay3LoqQr//PvDP9 cp1/bwi9I/xGgStj/BEh7VKogzOz8XIZwf+jIfthm0mbhj0ilIi/AynfcCzI5ymt Y3OCcwirnW55D/xBWEW3sOVWZU6ue0wVR1GbHm8ONMEcK4RpDOmJ8js5z5jXWDJx CJdCXHTEpjsPv+zO8vrfUOMgldBzSMUy1uwkFNkCqCLH38iAZB7sJIqLOlCt+9o8 3x9/Owryes828qnOntfKDKpDGgpV6lXBkJgI+4wHnUOdxytxhtiJf9/FH2g53cxJ mDnI0A0Lw259wuOWabJu =ofs3 -----END PGP SIGNATURE----- --=-=-=--