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.
