From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antoine Levitt Subject: Re: Completing with anything Date: Tue, 24 May 2011 20:30:06 +0200 Message-ID: <87d3j8vtn5.fsf@gmail.com> References: <87r5bhysp6.fsf@keller.adm.naquadah.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: (Stefan Monnier's message of "Tue, 24 May 2011 15:05:41 -0300") 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: Stefan Monnier Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org List-Id: emacs-orgmode.gnu.org 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.