Re: Completing with anything

[Antoine Levitt <antoine.levitt@gmail.com>]

24/05/11 20:05, Stefan Monnier
>> Oh well, I guess that I'm the only one who wants this kind of behaviour,
>> so I just ended up with an advice which seems to do the trick.  Sorry for
>> hijacking this thread.  In case anyone is interested:
>
> To get back to this discussion.  Before worrying about how to implement
> it, I'm wondering what should the behavior be.
>
> The way I look at it, the issue is whether the completion data returned
> by completion-at-point-functions is "exclusive": currently it is
> exclusive, which means that if that data leads to a completion failure,
> then the whole completion-at-point fails, even though there might be
> further functions on completion-at-point-functions which could return
> data that does lead to a successful completion.
>
> This "exclusive"ness is a bit similar to the must-match argument of
> completion-read: it presumes that the function knows that anything
> outside of the completion table is simply undesirable at point.
>
> This "exclusive" behavior is what causes you pain.  Now one possible
> strategy is to make the behavior non-exclusive and keep trying the next
> functions until one of them returns data that leads to a successful
> completion, which is largely what used to happen with
> comint-dynamic-complete-function.
>
> Another is to do it more selectively, flag some of
> completion-at-point-functions as "not-exclusive", meaning that if
> completion fails with those we should keep trying with subsequent
> functions.  E.g. the nick completion in rcirc could be flagged as
> non-exclusive since it applies everywhere, which in turn would let your
> dabbrev-expand kick in when nick-completion fails.

This seems to be the most flexible, while still keeping all the
completions in the same UI. I'd make the non-exclusive behaviour the
default though: let the functions that want to "take over" the
completion state it explicitely.