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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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