Re: Completing with anything

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

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

Yet another is to do what your defadvice does: let all completion
functions from completion-at-point-functions be exclusive with respect
to each other, but make them non-exclusive with respect to some
"fallback completion".


        Stefan