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

[Vitalie Spinu <spinuvit@gmail.com>]

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