Re: Completing with anything

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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