Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

Hi, 

The completion in emacs 24 is called twice. For example

(defun foo-completion ()
  (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t))
    (let ((token (match-string-no-properties 0))
	  (beg (match-beginning 0))
	  (end (match-end 0)))
      (message "%s:" token)
      (when (= end (point))
	(list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no)))))

(add-to-list 'completion-at-point-functions 'foo-completion) 
;; it is now (foo-completion lisp-completion-at-point t)

Place your point at the end of 'aaaa and you try to complete. I am
getting 

aaa:
aaaa:

in my message buffer. Which means the completion is called twice. I hope
this is not an intended behavior, as it might seriously interfere with
custom completion. For example I might want to have a different behavior
on the second consequent invocation of the completion (give a message,
modify the candidates etc).

Second problem is that if the completion is sole, the handling is not
passed over. For example after 'truncat I am getting a message "Sole
completion" and the lisp-completion-at-point is not reached at all. I
believe it's not how it should work.

In all the rest, new completion system is virtually perfect, thanks.

Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Vitalie Spinu <spinuvit@gmail.com>
>>>> on Fri, 16 Mar 2012 12:05:14 +0100 wrote:

  > Hi,

  > The completion in emacs 24 is called twice. For example

  > (defun foo-completion ()
  >   (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t))
  >     (let ((token (match-string-no-properties 0))
  > 	  (beg (match-beginning 0))
  > 	  (end (match-end 0)))
  >       (message "%s:" token)
  >       (when (= end (point))
  > 	(list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no)))))

  > (add-to-list 'completion-at-point-functions 'foo-completion)
  > ;; it is now (foo-completion lisp-completion-at-point t)

  > Place your point at the end of 'aaaa and you try to complete. I am
  > getting

  > aaa:
  > aaaa:

  > in my message buffer. Which means the completion is called twice. I hope
  > this is not an intended behavior, as it might seriously interfere with
  > custom completion. For example I might want to have a different behavior
  > on the second consequent invocation of the completion (give a message,
  > modify the candidates etc).

A related issue. Position after 'aaaa, try to complete. You will get a
"Sole completion" message. Press "space" or "M-b", or whatever, you will
get a message "aaaa:" which means that completion is repeated after any
other command. This is really bad, as my completion is calling an
external process and stalls emacs for a second, badly interfering with
the editing.

  > Second problem is that if the completion is sole, the handling is not
  > passed over. For example after 'truncat I am getting a message "Sole
  > completion" and the lisp-completion-at-point is not reached at all. I
  > believe it's not how it should work.

  > In all the rest, new completion system is virtually perfect, thanks.

  > Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

> The completion in Emacs 24 is called twice.  For example

> (defun foo-completion ()
>   (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t))
>     (let ((token (match-string-no-properties 0))
> 	  (beg (match-beginning 0))
> 	  (end (match-end 0)))
>       (message "%s:" token)
>       (when (= end (point))
> 	(list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no)))))

> (add-to-list 'completion-at-point-functions 'foo-completion) 
> ;; it is now (foo-completion lisp-completion-at-point t)

> Place your point at the end of 'aaaa and you try to complete. I am
> getting 

> aaa:
> aaaa:

> in my message buffer.  Which means the completion is called twice.

Not sure why, but not terribly problematic either.

> I hope this is not an intended behavior, as it might seriously
> interfere with custom completion.  For example I might want to have
> a different behavior on the second consequent invocation of the
> completion (give a message, modify the candidates etc).

No, completion-at-point-functions should return completion data and
can't know what that data will be used for.  Could be for TAB
completion, for on-the-fly popup completion à la auto-complete, for
display of the *Completions* buffer, or to decide whether we're still in
the same completion field (so as to pop-down the *Completions* buffer
when we leave that field), ...

> Second problem is that if the completion is sole, the handling is not
> passed over.

That's expected: completion is only passed over if the text doesn't
match any candidate.


        Stefan

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Stefan Monnier <monnier@iro.umontreal.ca>
>>>> on Fri, 16 Mar 2012 13:20:19 -0400 wrote:

  >> Place your point at the end of 'aaaa and you try to complete. I am
  >> getting 

  >> aaa:
  >> aaaa:

  >> in my message buffer.  Which means the completion is called twice.

  > Not sure why, but not terribly problematic either.

Right, unless the completion retrieval is computationally
intensive. Please see my other message with a more serious related
issue. It might give some clues.

  >> I hope this is not an intended behavior, as it might seriously
  >> interfere with custom completion.  For example I might want to have
  >> a different behavior on the second consequent invocation of the
  >> completion (give a message, modify the candidates etc).

  > No, completion-at-point-functions should return completion data and
  > can't know what that data will be used for.  Could be for TAB
  > completion, for on-the-fly popup completion à la auto-complete, for
  > display of the *Completions* buffer, or to decide whether we're still in
  > the same completion field (so as to pop-down the *Completions* buffer
  > when we leave that field), ...

In my case it's meaningful, as I retrieve completions from a
process. And if there is no process associated with a buffer, I want to
message: "Dude stop pressing TAB, there is no proc!!""

Also I think, popup functions should use a different list (like
completion-popup-functions). As users might want to use different sets
of completions. Also popup completions *must* be considerably less
computationally intensive, so it's probably a different set of functions
anyhow.

  >> Second problem is that if the completion is sole, the handling is not
  >> passed over.

  > That's expected: completion is only passed over if the text doesn't
  > match any candidate.

IMHO, this is far form an ideal default. Take an example of two
completions, one for symbols, another for functions. Or, even the etags
completion which is always the last, and might give many more candidates
with the same prefix.

Best, 
Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

>> Not sure why, but not terribly problematic either.
> Right, unless the completion retrieval is computationally intensive.

That could be a problem, but I haven't seen a circumstance where this is
the case yet.  This computation is only meant to decide which completion
table to use at a given buffer position.  The exact set of candidates
can be computed later.

> Please see my other message with a more serious related issue.
> It might give some clues.

I do not see your other message.  Is it on emacs-devel or a bug-report?

> In my case it's meaningful, as I retrieve completions from a
> process.

Then you should probably get your completions from the completion-table,
rather than from completion-at-point-functions.
IOW your completion-at-point-functions should return (without contacting
any process, other than maybe checking whether a process exists)
a completion table that's a function, e.g. built with
completion-table-dynamic, or using complete-with-action and it's *that*
function which contacts the process.

> Also I think, popup functions should use a different list (like
> completion-popup-functions).

That might be right (tho I hope it's not), but it doesn't eliminate the
fact that completion-at-point-functions might be called in
various circumstances.

> As users might want to use different sets of completions.

I expect completion-at-point-functions to be setup by major modes rather
than by users.

> Also popup completions *must* be considerably less computationally
> intensive, so it's probably a different set of functions anyhow.

The way I see it, completion-at-point-functions would instead include in
the `props' it returns, enough info to determine whether to use that
completion data for popup completion.

>>> Second problem is that if the completion is sole, the handling is not
>>> passed over.
>> That's expected: completion is only passed over if the text doesn't
>> match any candidate.
> IMHO, this is far form an ideal default.  Take an example of two
> completions, one for symbols, another for functions.  Or, even the
> etags completion which is always the last, and might give many more
> candidates with the same prefix.

You might be right.  The current behavior of "fall over" for
non-exclusive completion data is not cast in stone and is known to
have limitations.


        Stefan

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Lennart Borgman]

On Sat, Mar 17, 2012 at 23:34, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Not sure why, but not terribly problematic either.
>> Right, unless the completion retrieval is computationally intensive.
>
> That could be a problem, but I haven't seen a circumstance where this is
> the case yet.  This computation is only meant to decide which completion
> table to use at a given buffer position.  The exact set of candidates
> can be computed later.

If a parser is involved to make the candidate it can of course take long time.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Stefan Monnier <monnier@iro.umontreal.ca>
>>>> on Sat, 17 Mar 2012 18:34:31 -0400 wrote:

  >> Please see my other message with a more serious related issue.
  >> It might give some clues.

  > I do not see your other message.  Is it on emacs-devel or a bug-report?

Yes to emacs-devel,
http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00249.html

  >> In my case it's meaningful, as I retrieve completions from a
  >> process.

  > Then you should probably get your completions from the completion-table,
  > rather than from completion-at-point-functions.
  > IOW your completion-at-point-functions should return (without contacting
  > any process, other than maybe checking whether a process exists)
  > a completion table that's a function, e.g. built with
  > completion-table-dynamic, or using complete-with-action and it's *that*
  > function which contacts the process.

Thanks for the pointer. I was not aware of this distinction. But why
would that make a difference? Isn't the end result the same? Info is
silent on this.

  >> Also I think, popup functions should use a different list (like
  >> completion-popup-functions).

  > That might be right (tho I hope it's not), but it doesn't eliminate the
  > fact that completion-at-point-functions might be called in
  > various circumstances.

I've written auto-complete support and emacs-24 completion at point for
R. And it turned out that these two are really distinct features. One is
fast, cache based and sloppy, as it should not interfere with the
editing. Another one is exact and might be very slow, because it
contacts the associated process. The TAB completions can afford to be
slow, as there is no editing.

  >> As users might want to use different sets of completions.

  > I expect completion-at-point-functions to be setup by major modes rather
  > than by users.

Take auto-complete as an example. There are plenty of different
ac-sources, and users use whatever completion they want.

Related topic.  It would be great to have a separate "namespace" for all
buildin completions, or even a dedicated package. Then users and
developers can easily find buildin stuff.

For instance `completion-filename' instead of `comint-filename-completion',
 `completion-etags' instead of `tags-completion-at-point-function'
etc. Auto-complete package is a good example here - all sources start
with "ac-source-".

  >> Also popup completions *must* be considerably less computationally
  >> intensive, so it's probably a different set of functions anyhow.

  > The way I see it, completion-at-point-functions would instead include in
  > the `props' it returns, enough info to determine whether to use that
  > completion data for popup completion.

To return the props it still must be called, right? Indeed if the
completion function were aware that it was called from popup, then it
can simply return nil to be skipped. But, AFAICT, this is not currently
the case.

Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

>> I do not see your other message.  Is it on emacs-devel or a bug-report?
> Yes to emacs-devel,
> http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00249.html

Ah, not sure why I didn't see it, OK here it is:

> A related issue. Position after 'aaaa, try to complete. You will get a
> "Sole completion" message.  Press "space" or "M-b", or whatever, you will
> get a message "aaaa:" which means that completion is repeated after any
> other command.  This is really bad, as my completion is calling an
> external process and stalls emacs for a second, badly interfering with
> the editing.

Again, you're confused: the completion-at-point-functions do not perform
completion, they just return the data about what completion table to use
at point.

>> Then you should probably get your completions from the completion-table,
>> rather than from completion-at-point-functions.
>> IOW your completion-at-point-functions should return (without contacting
>> any process, other than maybe checking whether a process exists)
>> a completion table that's a function, e.g. built with
>> completion-table-dynamic, or using complete-with-action and it's *that*
>> function which contacts the process.
> Thanks for the pointer.  I was not aware of this distinction.  But why
> would that make a difference?

Because the completion table may or may not be used after being returned
by completion-at-point-function.  And it may be called with a different
string than the one in the buffer.

>>> Also I think, popup functions should use a different list (like
>>> completion-popup-functions).
>> That might be right (tho I hope it's not), but it doesn't eliminate the
>> fact that completion-at-point-functions might be called in
>> various circumstances.
> I've written auto-complete support and emacs-24 completion at point
> for R.  And it turned out that these two are really distinct features.
> One is fast, cache based and sloppy, as it should not interfere with
> the editing.  Another one is exact and might be very slow, because it
> contacts the associated process.  The TAB completions can afford to be
> slow, as there is no editing.

Interesting.

So the completion candidates displayed in R-mode for auto-complete are
different than the ones used for TAB?

> Take auto-complete as an example.  There are plenty of different
> ac-sources, and users use whatever completion they want.

From what I can tell, this is largely because the major modes don't
provide this info themselves yet.

> Related topic.  It would be great to have a separate "namespace" for all
> buildin completions, or even a dedicated package. Then users and
> developers can easily find buildin stuff.
> For instance `completion-filename' instead of `comint-filename-completion',
> `completion-etags' instead of `tags-completion-at-point-function'
> etc.  Auto-complete package is a good example here - all sources start
> with "ac-source-".

Hmm... more consistency in the naming might be good here, indeed.
It's important to keep the "<package>-" prefix since I don't want to
consider all of this as part of Emacs's "core", but maybe we could
settle on "<something>-completion-at-point-function" or maybe something
shorter than that.

>>> Also popup completions *must* be considerably less computationally
>>> intensive, so it's probably a different set of functions anyhow.
>> The way I see it, completion-at-point-functions would instead include in
>> the `props' it returns, enough info to determine whether to use that
>> completion data for popup completion.
> To return the props it still must be called, right? Indeed if the
> completion function were aware that it was called from popup, then it
> can simply return nil to be skipped. But, AFAICT, this is not currently
> the case.

As mentioned, completion-point-functions should not work hard: it should
just return the boundaries of what it would consider as "the text to
complete if we were to complete it", and what code to use to get the
completion candidates (again, in case we do decide to perform
completion).

For auto-complete, we might need to look at the completion candidates
very often, in order to decide whether or not to popup a set
of completions.  But I'd hope that the `props' can provide the needed
data (e.g. a predicate function to decide whether or not it's worth the
trouble getting the list of candidates).

Linking completion-at-point-functions and auto-complete is not done yet,
clearly (and will probably also add more completion-metadata).


        Stefan

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Stefan Monnier <monnier@iro.umontreal.ca>
>>>> on Sat, 17 Mar 2012 22:03:44 -0400 wrote:

  >> A related issue. Position after 'aaaa, try to complete. You will get a
  >> "Sole completion" message.  Press "space" or "M-b", or whatever, you will
  >> get a message "aaaa:" which means that completion is repeated after any
  >> other command.  This is really bad, as my completion is calling an
  >> external process and stalls emacs for a second, badly interfering with
  >> the editing.

  > Again, you're confused: the completion-at-point-functions do not perform
  > completion, they just return the data about what completion table to use
  > at point.

Ok, I see it more clearly now, with your auto-complete point latter,
thanks. Will rewrite and see if it gets better.

(...)

  >> I've written auto-complete support and emacs-24 completion at point
  >> for R.  And it turned out that these two are really distinct features.
  >> One is fast, cache based and sloppy, as it should not interfere with
  >> the editing.  Another one is exact and might be very slow, because it
  >> contacts the associated process.  The TAB completions can afford to be
  >> slow, as there is no editing.

  > Interesting.

  > So the completion candidates displayed in R-mode for auto-complete are
  > different than the ones used for TAB?

Yes, and no. What I meant is that the underlying mechanisms are very
different.  99.99% of the time the completion candidates are the same,
but there are objects which are not meaningful to cache, like arguments
of the user functions, or components of the recursive structures (lists,
environments, data.frames etc.). In this cases AC also calls the
process, and it's usually fast. But in some extreme corner cases, like
if user changed a function in an attached package, AC will still use the
cached version.'

  > Hmm... more consistency in the naming might be good here, indeed.
  > It's important to keep the "<package>-" prefix since I don't want to
  > consider all of this as part of Emacs's "core", but maybe we could
  > settle on "<something>-completion-at-point-function" or maybe something
  > shorter than that.

I am a fan of the -completion postfix convention. It's easy to match in
apropos, anything or IDO regexp: comint-filename-completion,
tags-completion, imenu-completion, imenu-in-same-mode-completion,
words-in-same-buffer-commpletion etc. It can get pretty long by itself,
so a short postfix is better.

Best, 
Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

> Yes, and no. What I meant is that the underlying mechanisms are very
> different.  99.99% of the time the completion candidates are the same,
> but there are objects which are not meaningful to cache, like arguments
> of the user functions, or components of the recursive structures (lists,
> environments, data.frames etc.).  In this cases AC also calls the
> process, and it's usually fast.  But in some extreme corner cases, like
> if user changed a function in an attached package, AC will still use the
> cached version.'

So, IIUC it would be perfectly OK for TAB completion to use the AC code.

>> Hmm... more consistency in the naming might be good here, indeed.
>> It's important to keep the "<package>-" prefix since I don't want to
>> consider all of this as part of Emacs's "core", but maybe we could
>> settle on "<something>-completion-at-point-function" or maybe something
>> shorter than that.
> I am a fan of the -completion postfix convention.  It's easy to match in
> apropos, anything or IDO regexp: comint-filename-completion,
> tags-completion, imenu-completion, imenu-in-same-mode-completion,
> words-in-same-buffer-commpletion etc.  It can get pretty long by itself,
> so a short postfix is better.

But I suspect it will generate false positives because it's not
specific enough.  Maybe "-completion-data"?


        Stefan

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Stefan Monnier <monnier@iro.umontreal.ca>
>>>> on Sun, 18 Mar 2012 11:42:27 -0400 wrote:

  >> Yes, and no. What I meant is that the underlying mechanisms are very
  >> different.  99.99% of the time the completion candidates are the same,
  >> but there are objects which are not meaningful to cache, like arguments
  >> of the user functions, or components of the recursive structures (lists,
  >> environments, data.frames etc.).  In this cases AC also calls the
  >> process, and it's usually fast.  But in some extreme corner cases, like
  >> if user changed a function in an attached package, AC will still use the
  >> cached version.'

  > So, IIUC it would be perfectly OK for TAB completion to use the AC code.

Indeed, you could be right that always one-for-all completion function
might be made enough for the prefix completion. But I don't see how popup
menu can properly deal with partial completions for example, or
expansions a la yas. So you would still need a separate list for those.

And the old argument still stands - would the user like to have the same
redundant list of completion functions for C-M-i and popup menu?  

  >>> Hmm... more consistency in the naming might be good here, indeed.
  >>> It's important to keep the "<package>-" prefix since I don't want to
  >>> consider all of this as part of Emacs's "core", but maybe we could
  >>> settle on "<something>-completion-at-point-function" or maybe something
  >>> shorter than that.
  >> I am a fan of the -completion postfix convention.  It's easy to match in
  >> apropos, anything or IDO regexp: comint-filename-completion,
  >> tags-completion, imenu-completion, imenu-in-same-mode-completion,
  >> words-in-same-buffer-commpletion etc.  It can get pretty long by itself,
  >> so a short postfix is better.

  > But I suspect it will generate false positives because it's not
  > specific enough.  Maybe "-completion-data"?

Maybe -c-a-p,  or -c-a-p-data? 

Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

>>> Yes, and no. What I meant is that the underlying mechanisms are very
>>> different.  99.99% of the time the completion candidates are the same,
>>> but there are objects which are not meaningful to cache, like arguments
>>> of the user functions, or components of the recursive structures (lists,
>>> environments, data.frames etc.).  In this cases AC also calls the
>>> process, and it's usually fast.  But in some extreme corner cases, like
>>> if user changed a function in an attached package, AC will still use the
>>> cached version.'
>> So, IIUC it would be perfectly OK for TAB completion to use the AC code.
> Indeed, you could be right that always one-for-all completion function
> might be made enough for the prefix completion. But I don't see how popup
> menu can properly deal with partial completions for example,

I'd expect popup menus wouldn't use the partial-completion style, but
that's not a problem: the completion-styles only care about what to do
once we have the completion data, whereas completion-at-point-function
does not care about it at all since it only cares about providing that
completion data.
Every kind of completion UI can use its own (set of) completion
style(s).  If AC can be made to use a partial-completion style, great,
but if not that's just as well.

> or expansions a la yas.

I guess you're referring to some part of yasnippet, but I don't know
which part, nor why it is related to completion-at-point-functions.

> So you would still need a separate list for those.

As explained, partial-completion is another problem.  As for abbrev-like
"completion+expansion", I don't see why it can't work with AC (and if
it can't work, the completion-at-point-function can return some data
in its `props' making it clear it can't be used for AC).

> And the old argument still stands - would the user like to have the same
> redundant list of completion functions for C-M-i and popup menu?

I don't see why not.  Tho, for completions like etags-completion or
dabbrev-completion, i.e. forms of completions which don't actually know
whether the candidates they return are actually relevant at point, maybe
we'd like to make exceptions (like we already do for dabbrev-completions
which are bound to a special key rather than to TAB).

>>>> Hmm... more consistency in the naming might be good here, indeed.
>>>> It's important to keep the "<package>-" prefix since I don't want to
>>>> consider all of this as part of Emacs's "core", but maybe we could
>>>> settle on "<something>-completion-at-point-function" or maybe something
>>>> shorter than that.
>>> I am a fan of the -completion postfix convention.  It's easy to match in
>>> apropos, anything or IDO regexp: comint-filename-completion,
>>> tags-completion, imenu-completion, imenu-in-same-mode-completion,
>>> words-in-same-buffer-commpletion etc.  It can get pretty long by itself,
>>> so a short postfix is better.
>> But I suspect it will generate false positives because it's not
>> specific enough.  Maybe "-completion-data"?
> Maybe -c-a-p,  or -c-a-p-data?

I used "-capf" within the code of completion-at-point, but I think it's
too cryptic for use outside of that context.


        Stefan

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Vitalie Spinu]

>>>> Stefan Monnier <monnier@IRO.UMontreal.CA>
>>>> on Sun, 18 Mar 2012 20:53:11 -0400 wrote:

  >> or expansions a la yas.

  > I guess you're referring to some part of yasnippet, but I don't know
  > which part, nor why it is related to completion-at-point-functions.

Yes, I mean the expansion of abbreviations at point, like yasnippet
does. But, it looks like you don't consider it as a completion in the
first place.

  >> So you would still need a separate list for those.

  > As explained, partial-completion is another problem.  As for abbrev-like
  > "completion+expansion", I don't see why it can't work with AC (and if
  > it can't work, the completion-at-point-function can return some data
  > in its `props' making it clear it can't be used for AC).

Hmm, ... right, still cannot get used to the concept.

  >> And the old argument still stands - would the user like to have the same
  >> redundant list of completion functions for C-M-i and popup menu?

  > I don't see why not.  Tho, for completions like etags-completion or
  > dabbrev-completion, i.e. forms of completions which don't actually know
  > whether the candidates they return are actually relevant at point, maybe
  > we'd like to make exceptions (like we already do for dabbrev-completions
  > which are bound to a special key rather than to TAB).

Good point, given the current mechanism, it's trivial to write a custom
completion, with custom list of capfs and bind it to a key. 

  > I used "-capf" within the code of completion-at-point, but I think it's
  > too cryptic for use outside of that context.

Sounds great to me! It's easy to spell, search for and remember, and is
more specific than -data. At the end it's just a convention to be used
to, and from each function's documentation it will be clear what it
means.

Thanks, 
Vitalie.

Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion.

[Stefan Monnier]

>>> or expansions a la yas.
>> I guess you're referring to some part of yasnippet, but I don't know
>> which part, nor why it is related to completion-at-point-functions.
> Yes, I mean the expansion of abbreviations at point, like yasnippet
> does.  But, it looks like you don't consider it as a completion in the
> first place.

I don't know yasnippet's abbreviation's expansion behavior, but assuming
it works basically along the same lines as abbrev, then the completion
part is only the part that finds an abbrev based on the text already
typed (and there may be several such abbrevs, so you get the usual
behavior of completions), whereas the expansion is a post-processing
step which only happens if the completion found a single candidate (and
this is performed with the :exit-function that can be set in
completion-data's `props').
See bibtex.el for an example use of this functionality.

>> I used "-capf" within the code of completion-at-point, but I think it's
>> too cryptic for use outside of that context.
> Sounds great to me! It's easy to spell, search for and remember, and is
> more specific than -data. At the end it's just a convention to be used
> to, and from each function's documentation it will be clear what it
> means.

Then maybe we should go with "-completion-capf" (more specific
than -data, but still makes it clear it's related to completion, even
for people not familiar with -capf).


        Stefan