From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: Completing with anything Date: Mon, 21 Mar 2011 11:19:41 -0400 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: text/plain X-Trace: dough.gmane.org 1300720804 31845 80.91.229.12 (21 Mar 2011 15:20:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2011 15:20:04 +0000 (UTC) Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 21 16:19:58 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 1Q1gth-00062d-Cu for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 16:19:57 +0100 Original-Received: from localhost ([127.0.0.1]:58671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1gtg-0006v2-6g for ged-emacs-devel@m.gmane.org; Mon, 21 Mar 2011 11:19:56 -0400 Original-Received: from [140.186.70.92] (port=42257 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q1gtV-0006tH-3X for emacs-devel@gnu.org; Mon, 21 Mar 2011 11:19:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q1gtT-0003Wf-3t for emacs-devel@gnu.org; Mon, 21 Mar 2011 11:19:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:58425 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q1gtS-0003WT-Vl; Mon, 21 Mar 2011 11:19:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEMJh01Ld/X5/2dsb2JhbAClc3iITbgkhWMElWk X-IronPort-AV: E=Sophos;i="4.63,219,1299474000"; d="scan'208";a="97418710" Original-Received: from 75-119-245-249.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.249]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 21 Mar 2011 11:19:41 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5604F58AF5; Mon, 21 Mar 2011 11:19:41 -0400 (EDT) In-Reply-To: (Julien Danjou's message of "Mon, 21 Mar 2011 12:23:09 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:137481 gmane.emacs.orgmode:39882 Archived-At: >> 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. That sentence is obsolete. Sorry 'bout that. A collection can be any function, including a lambda expression. > 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 completion-at-point-function is meant to provide just the possible completion candidates for the kind of object being completed. Which ones of these will be actually considered will then depend on the actual text in the buffer and the completion-styles in use. A missing feature in minibuffer.el is the ability to specify different completion styles for different circumstances. > And try to complete a "L", it will complete to Lionel. That depends on completion-styles. Tho I must admit that I can't think of any completion-style where it would make sense to complete "L" to "Steve" when "Lionel" is a valid candidate (I have an experimental "forgiving" completion-style which could be convinced to treat the "L" as a typo and complete to "Steve" or "John", but in the presence of "Lionel" it would prefer not to). > Just because completion-at-point is trying to be smarter than my > function, re-guessing which items from the collection are > good candidates. Your function's job is not to guess which items are good candidates, but rather to return all the candidates in the category being completed. > Something my function already does (well, not in this example, but in > real life). A completion-at-point-function is allowed to look at the buffer text and weed out elements that don't match, but it does not have to (and I'd recommend that it does not except when there's a significant performance benefit, since it may weed out elements that the completion-style in use may actually consider as valid candidates). It is the job of completion-in-region-functions. Stefan