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