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: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. Date: Sat, 17 Mar 2012 18:34:31 -0400 Message-ID: References: <87haxoyff9.fsf@gmail.com> <87sjh8wdbw.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1332023682 14561 80.91.229.3 (17 Mar 2012 22:34:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 22:34:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 17 23:34:41 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 1S92Ct-0001fJ-7L for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2012 23:34:39 +0100 Original-Received: from localhost ([::1]:47113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S92Cs-0001VP-An for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2012 18:34:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38930) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S92Cp-0001Um-JJ for emacs-devel@gnu.org; Sat, 17 Mar 2012 18:34:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S92Cn-0002kX-R5 for emacs-devel@gnu.org; Sat, 17 Mar 2012 18:34:35 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:18441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S92Cn-0002kR-Mh for emacs-devel@gnu.org; Sat, 17 Mar 2012 18:34:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9soXdS/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="168624674" Original-Received: from 108-161-119-82.dsl.teksavvy.com (HELO pastel.home) ([108.161.119.82]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 17 Mar 2012 18:34:32 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 127655946A; Sat, 17 Mar 2012 18:34:31 -0400 (EDT) In-Reply-To: <87sjh8wdbw.fsf@gmail.com> (Vitalie Spinu's message of "Fri, 16 Mar 2012 20:33:23 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:149114 Archived-At: >> Not sure why, but not terribly problematic either. > Right, unless the completion retrieval is computationally intensive. That could be a problem, but I haven't seen a circumstance where this is the case yet. This computation is only meant to decide which completion table to use at a given buffer position. The exact set of candidates can be computed later. > Please see my other message with a more serious related issue. > It might give some clues. I do not see your other message. Is it on emacs-devel or a bug-report? > In my case it's meaningful, as I retrieve completions from a > process. Then you should probably get your completions from the completion-table, rather than from completion-at-point-functions. IOW your completion-at-point-functions should return (without contacting any process, other than maybe checking whether a process exists) a completion table that's a function, e.g. built with completion-table-dynamic, or using complete-with-action and it's *that* function which contacts the process. > Also I think, popup functions should use a different list (like > completion-popup-functions). That might be right (tho I hope it's not), but it doesn't eliminate the fact that completion-at-point-functions might be called in various circumstances. > As users might want to use different sets of completions. I expect completion-at-point-functions to be setup by major modes rather than by users. > Also popup completions *must* be considerably less computationally > intensive, so it's probably a different set of functions anyhow. The way I see it, completion-at-point-functions would instead include in the `props' it returns, enough info to determine whether to use that completion data for popup completion. >>> 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. You might be right. The current behavior of "fall over" for non-exclusive completion data is not cast in stone and is known to have limitations. Stefan