Re: ERC completion

[Antoine Levitt]

02/05/11 20:04, Stefan Monnier
>>>> I seem to recall talks of priority for completions. Couldn't that be
>>>> used here? That way, I'd set completion-at-point-functions to something
>>>> that returns the list of dabbrev expands with a low priority, and every
>>>> other completion would take precedence over it.
>>> By placing it at the end of the hook, you're giving it the lowest
>>> priority.
>> Cool! Then all that'd be needed is to write a dabbrev-completions
>> function that'd return all completions, as found by dabbrev, and set it
>> at the end of the hook. Then erc nick completions would take precedence,
>> and life would be good again.
>
> No, I think your problem is not that dabbrev had too high a priority,
> but rather than erc-nick completion is too eager to complete
> everywhere, and never lets the lower-priority completions (such as
> dabbrev) play.

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

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?