From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306261832 3791 80.91.229.12 (24 May 2011 18:30:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 18:30:32 +0000 (UTC) Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 24 20:30:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QOwN8-0001hX-1s for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 20:30:26 +0200 Original-Received: from localhost ([::1]:33531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOwN7-0003ng-95 for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 14:30:25 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOwN3-0003ks-Ex for emacs-devel@gnu.org; Tue, 24 May 2011 14:30:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOwN2-0005zN-NY for emacs-devel@gnu.org; Tue, 24 May 2011 14:30:21 -0400 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:53796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOwMy-0005yM-O6; Tue, 24 May 2011 14:30:16 -0400 Original-Received: by wyf19 with SMTP id 19so6427827wyf.0 for ; Tue, 24 May 2011 11:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=R+lV4QFnS5p1msK14KiMu9qxUEpjf71/ZNxHo0aAhOA=; b=UGy3ztjUeIFKEO4v50PZVvobdQzu3vzKdfGkYZ4UIumpHjivL+RwvPFufJKSHOdl1h jhl5exLT3p12aqDdYlq0ytMpnNLZ9lkm2Y7VE6wVJnFR6qWHXq04Pn3o0RqW0yhYUso1 jLiHXMg8D5za0WM/lSjWXidT85qAhH+L+wnVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=xcafTkhsIUxrxzkncl+tffhrzjz6XOqMIS8mmZ6nslaFiVwR9pc94BPy2effC2FbH4 MEphKCEX/LaFApr76R3ecsJgazZndfaPBD773KbtxipFXJc1/NPixs2Mf2WR/sSnEp2g qinCuwNEtdN/UtBC2A1XRgg8Mtpgag+oU40zw= Original-Received: by 10.216.230.215 with SMTP id j65mr3518997weq.24.1306261815566; Tue, 24 May 2011 11:30:15 -0700 (PDT) Original-Received: from lambda (ney92-7-78-233-218-202.fbx.proxad.net [78.233.218.202]) by mx.google.com with ESMTPS id g58sm3980746wen.44.2011.05.24.11.30.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 11:30:14 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Tue, 24 May 2011 15:05:41 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139684 gmane.emacs.orgmode:42202 Archived-At: 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.