From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306260355 25863 80.91.229.12 (24 May 2011 18:05:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 18:05:55 +0000 (UTC) Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Antoine Levitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 24 20:05:51 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 1QOvzK-0002OS-2K for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 20:05:50 +0200 Original-Received: from localhost ([::1]:49950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOvzJ-0000zy-KC for ged-emacs-devel@m.gmane.org; Tue, 24 May 2011 14:05:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOvzG-0000zm-RL for emacs-devel@gnu.org; Tue, 24 May 2011 14:05:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOvzF-0001vs-Vq for emacs-devel@gnu.org; Tue, 24 May 2011 14:05:46 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:59641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOvzF-0001vo-Tn; Tue, 24 May 2011 14:05:45 -0400 Original-Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:36232 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QOvzF-0000XL-IB; Tue, 24 May 2011 14:05:45 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D934B662FB; Tue, 24 May 2011 15:05:41 -0300 (ART) In-Reply-To: <87lixwkzi4.fsf@gmail.com> (Antoine Levitt's message of "Tue, 24 May 2011 15:18:59 +0200") 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, 3) X-Received-From: 140.186.70.10 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:139682 gmane.emacs.orgmode:42201 Archived-At: > 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