Re: ERC completion

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

> Right, I think I (finally) see. I thought the completion-at-point thingy
> was designed from the ground up to merge several completion sources,
> which is why I was thoroughly confused by this conversation.

It is designed for this, but for completions which are context
sensitive.

> Judging from the various codes on the internet
> (http://www.emacswiki.org/emacs/HippieExpand for instance), several
> others have a need for this kind of things.

Yes, that's why I'm keeping this thread open.

> What about a switch, completion-include-alternate-completions or
> something, that'd make completion-at-point do what I thought it did, ie
> also run the other completion-at-point functions, and not stop at the
> first one that returns non-nil, and then merge all these completions,
> hopefully doing something clever when the START and END of these
> different completions change between each one? Would that be doable?

I'm thinking of letting the completion function return some :fallthrough
option which would tell completion-at-point that in case the completion
data it returned leads to a completion failure, then it should continue
with the next completion function.

And yes, if the start&end of the various alternatives is the same, we
can merge them easily via completion-table-in-turn (which would have
effects such as: first try prefix-nick-completion, then
prefix-dabbrev-completion, then partial-nick-completion, then
partial-dabbrev-completion).  OTOH if start&end aren't the same it
forces separate calls to the completion UI, relying on the completion UI
to tell us whether the completion operation (whether it is to perform
completion, or to display completions, or whatever else)
was successful in order to know whether to try with the next
completion data.


        Stefan