From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: Re: Completing with anything Date: Tue, 24 May 2011 15:05:41 -0300 Message-ID: References: <87r5bhysp6.fsf@keller.adm.naquadah.org> <87mxm2na63.fsf@member.fsf.org> <87vd0qfhu3.fsf@member.fsf.org> <87y63jpii5.fsf@keller.adm.naquadah.org> <871v0ecwe4.fsf@keller.adm.naquadah.org> <87aaecihl2.fsf@gmail.com> <87lixwkzi4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <87lixwkzi4.fsf@gmail.com> (Antoine Levitt's message of "Tue, 24 May 2011 15:18:59 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org To: Antoine Levitt Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org List-Id: emacs-orgmode.gnu.org > 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