From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. Date: Fri, 16 Mar 2012 20:33:23 +0100 Organization: EUR Message-ID: <87sjh8wdbw.fsf@gmail.com> References: <87haxoyff9.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1331965459 11959 80.91.229.3 (17 Mar 2012 06:24:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 06:24:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 17 07:24:18 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S8n3p-0005Xg-QF for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2012 07:24:17 +0100 Original-Received: from localhost ([::1]:35757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8n3p-0006St-5Z for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2012 02:24:17 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8cu3-0002yu-Fn for emacs-devel@gnu.org; Fri, 16 Mar 2012 15:33:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8cu1-0005gm-LD for emacs-devel@gnu.org; Fri, 16 Mar 2012 15:33:31 -0400 Original-Received: from mail-ee0-f41.google.com ([74.125.83.41]:38669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8cu1-0005gb-CU for emacs-devel@gnu.org; Fri, 16 Mar 2012 15:33:29 -0400 Original-Received: by eeke53 with SMTP id e53so2577000eek.0 for ; Fri, 16 Mar 2012 12:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=bpUt79HYeaDqq38F1tgpk94UrYKsYtmJgXwjPuuTEQ4=; b=Ymu1x6o4EIcv0oqRjt4F3foCiyIejKJ4uhcLUo7GrBHH2Gxue8Y7knWL6HItWEtWEj LwBiN/TyW0tBNvwP2HucOb+ySU0anAxMOQufjC+8bVeJkWbMLKv6KF+QtwnWHAJ28eJk eagBCxfBO2PEwnJV0UXbvy1knprlgL6etY39NwgmBZYMqmPfWl5xuJuo36IuK5YIO8dx hJn2V+H6CDmnW89+7gCAbLC8Mmv8PJSbNAjOx63/3djCWj2KUE+pvdo53GU+kIma+4m9 M2STQQuGa3xy4B2aorhgWtRqdSgLeeDIiwx3RngzsPf/Nvbg7zgLzyVKezIMclRcLBoR PodQ== Original-Received: by 10.14.127.12 with SMTP id c12mr484368eei.19.1331926406451; Fri, 16 Mar 2012 12:33:26 -0700 (PDT) Original-Received: from localhost (e138158.upc-e.chello.nl. [213.93.138.158]) by mx.google.com with ESMTPS id y11sm21557338eem.3.2012.03.16.12.33.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 12:33:25 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 16 Mar 2012 13:20:19 -0400") User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.83.41 X-Mailman-Approved-At: Sat, 17 Mar 2012 02:24:16 -0400 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:149109 Archived-At: >>>> Stefan Monnier >>>> on Fri, 16 Mar 2012 13:20:19 -0400 wrote: >> Place your point at the end of 'aaaa and you try to complete. I am >> getting=20 >> aaa: >> aaaa: >> in my message buffer. Which means the completion is called twice. > Not sure why, but not terribly problematic either. Right, unless the completion retrieval is computationally intensive. Please see my other message with a more serious related issue. It might give some clues. >> I hope this is not an intended behavior, as it might seriously >> interfere with custom completion. For example I might want to have >> a different behavior on the second consequent invocation of the >> completion (give a message, modify the candidates etc). > No, completion-at-point-functions should return completion data and > can't know what that data will be used for. Could be for TAB > completion, for on-the-fly popup completion =C3=A0 la auto-complete, for > display of the *Completions* buffer, or to decide whether we're still in > the same completion field (so as to pop-down the *Completions* buffer > when we leave that field), ... In my case it's meaningful, as I retrieve completions from a process. And if there is no process associated with a buffer, I want to message: "Dude stop pressing TAB, there is no proc!!"" Also I think, popup functions should use a different list (like completion-popup-functions). As users might want to use different sets of completions. Also popup completions *must* be considerably less computationally intensive, so it's probably a different set of functions anyhow. >> Second problem is that if the completion is sole, the handling is not >> passed over. > That's expected: completion is only passed over if the text doesn't > match any candidate. IMHO, this is far form an ideal default. Take an example of two completions, one for symbols, another for functions. Or, even the etags completion which is always the last, and might give many more candidates with the same prefix. Best,=20 Vitalie.