From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Julien Danjou's message of "Mon, 21 Mar 2011 12:23:09 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 To: Tassilo Horn Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org List-Id: emacs-orgmode.gnu.org >> 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