From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: ERC completion Date: Mon, 02 May 2011 21:47:51 -0300 Message-ID: References: <87y62ved2o.fsf@gmail.com> <871v0mu033.fsf@gmail.com> <87liyujgxv.fsf@gmail.com> <87liytfqo5.fsf@gmail.com> <87wriciwnc.fsf@gmail.com> <87d3k1ceqj.fsf@gmail.com> <87fwowx03n.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304383687 2973 80.91.229.12 (3 May 2011 00:48:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 3 May 2011 00:48:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Antoine Levitt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 03 02:48:00 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 1QH3mR-0000y6-GT for ged-emacs-devel@m.gmane.org; Tue, 03 May 2011 02:47:59 +0200 Original-Received: from localhost ([::1]:37093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH3mQ-0006WA-SV for ged-emacs-devel@m.gmane.org; Mon, 02 May 2011 20:47:58 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH3mN-0006W3-EL for emacs-devel@gnu.org; Mon, 02 May 2011 20:47:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QH3mM-00052Q-B7 for emacs-devel@gnu.org; Mon, 02 May 2011 20:47:55 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:54092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH3mM-00052L-7M for emacs-devel@gnu.org; Mon, 02 May 2011 20:47:54 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:61055 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QH3mL-00073v-MU; Mon, 02 May 2011 20:47:54 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0A4AC66239; Mon, 2 May 2011 21:47:51 -0300 (ART) In-Reply-To: <87fwowx03n.fsf@gmail.com> (Antoine Levitt's message of "Mon, 02 May 2011 23:29:32 +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:139023 Archived-At: > Right, I think I (finally) see. I thought the completion-at-point thingy > was designed from the ground up to merge several completion sources, > which is why I was thoroughly confused by this conversation. It is designed for this, but for completions which are context sensitive. > Judging from the various codes on the internet > (http://www.emacswiki.org/emacs/HippieExpand for instance), several > others have a need for this kind of things. Yes, that's why I'm keeping this thread open. > What about a switch, completion-include-alternate-completions or > something, that'd make completion-at-point do what I thought it did, ie > also run the other completion-at-point functions, and not stop at the > first one that returns non-nil, and then merge all these completions, > hopefully doing something clever when the START and END of these > different completions change between each one? Would that be doable? I'm thinking of letting the completion function return some :fallthrough option which would tell completion-at-point that in case the completion data it returned leads to a completion failure, then it should continue with the next completion function. And yes, if the start&end of the various alternatives is the same, we can merge them easily via completion-table-in-turn (which would have effects such as: first try prefix-nick-completion, then prefix-dabbrev-completion, then partial-nick-completion, then partial-dabbrev-completion). OTOH if start&end aren't the same it forces separate calls to the completion UI, relying on the completion UI to tell us whether the completion operation (whether it is to perform completion, or to display completions, or whatever else) was successful in order to know whether to try with the next completion data. Stefan