From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel Subject: Re: ERC completion Date: Mon, 02 May 2011 23:29:32 +0200 Message-ID: <87fwowx03n.fsf@gmail.com> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1304371789 9803 80.91.229.12 (2 May 2011 21:29:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 May 2011 21:29:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 02 23:29:44 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 1QH0gY-0003sb-Hi for ged-emacs-devel@m.gmane.org; Mon, 02 May 2011 23:29:42 +0200 Original-Received: from localhost ([::1]:38577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH0gX-0005ul-Ud for ged-emacs-devel@m.gmane.org; Mon, 02 May 2011 17:29:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH0gU-0005uU-Gn for emacs-devel@gnu.org; Mon, 02 May 2011 17:29:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QH0gT-0007ml-40 for emacs-devel@gnu.org; Mon, 02 May 2011 17:29:38 -0400 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:42221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QH0gS-0007mh-Qr for emacs-devel@gnu.org; Mon, 02 May 2011 17:29:36 -0400 Original-Received: by wwb39 with SMTP id 39so5652041wwb.30 for ; Mon, 02 May 2011 14:29:36 -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:message-id :user-agent:mime-version:content-type; bh=r2Igc8UTgdtRdOxynpfoR8jSyHjdCqTFohWNHQFswPM=; b=gD0jNWjl2gPunr/4m5xFnlTlTn+ykjuAO89URxeB6DLOSkfh1MWKTJ0OeSPlDfgfjj 5Nlzq7jzca66mREEtVyia6zGtRN3zK2hiRVTjJFih2klhNmJzGiqn9i8AyHdP0oNs3D/ G5hgh2/DZSwJYXPLWqM3/yM1jwGIk9wrfh5uQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=x7XPr8XOfp2bU+QATXKWcoJtQv0Ar/jR5crxLEM+1woJkrVsT6fyAHBRqXcdmnL6jy L+QIe0gryL3fGca9oD9IR0p0mbudjbelvXuAdT1kdSEudCkUbkGgBE7LUwol6HsUvkkN Ebs2g0sihiU54Y2C0Wu49W8MhHL+lFS7Ftklo= Original-Received: by 10.227.59.210 with SMTP id m18mr4409406wbh.112.1304371775989; Mon, 02 May 2011 14:29:35 -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 e13sm3625458wbi.57.2011.05.02.14.29.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2011 14:29:34 -0700 (PDT) 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.49 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:139007 Archived-At: 02/05/11 20:04, Stefan Monnier >>>> I seem to recall talks of priority for completions. Couldn't that be >>>> used here? That way, I'd set completion-at-point-functions to something >>>> that returns the list of dabbrev expands with a low priority, and every >>>> other completion would take precedence over it. >>> By placing it at the end of the hook, you're giving it the lowest >>> priority. >> Cool! Then all that'd be needed is to write a dabbrev-completions >> function that'd return all completions, as found by dabbrev, and set it >> at the end of the hook. Then erc nick completions would take precedence, >> and life would be good again. > > No, I think your problem is not that dabbrev had too high a priority, > but rather than erc-nick completion is too eager to complete > everywhere, and never lets the lower-priority completions (such as > dabbrev) play. 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. 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. 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?