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 22:03:44 -0400 Message-ID: References: <87haxoyff9.fsf@gmail.com> <87sjh8wdbw.fsf@gmail.com> <87haxmx0o7.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1332036239 19351 80.91.229.3 (18 Mar 2012 02:03:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Mar 2012 02:03:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 18 03:03:56 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 1S95TN-0000CM-2q for ged-emacs-devel@m.gmane.org; Sun, 18 Mar 2012 03:03:53 +0100 Original-Received: from localhost ([::1]:37639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S95TM-0005JJ-BT for ged-emacs-devel@m.gmane.org; Sat, 17 Mar 2012 22:03:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S95TJ-0005Ip-9v for emacs-devel@gnu.org; Sat, 17 Mar 2012 22:03:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S95TH-0006OX-6P for emacs-devel@gnu.org; Sat, 17 Mar 2012 22:03:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:20729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S95TH-0006OM-21 for emacs-devel@gnu.org; Sat, 17 Mar 2012 22:03:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9soXdS/2dsb2JhbACBX5x7eYhwnhmGGQSORIxVhAk X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="168644135" 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 22:03:44 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 31C075946A; Sat, 17 Mar 2012 22:03:44 -0400 (EDT) In-Reply-To: <87haxmx0o7.fsf@gmail.com> (Vitalie Spinu's message of "Sun, 18 Mar 2012 00:33:44 +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.181 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:149118 Archived-At: >> I do not see your other message. Is it on emacs-devel or a bug-report? > Yes to emacs-devel, > http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00249.html Ah, not sure why I didn't see it, OK here it is: > A related issue. Position after 'aaaa, try to complete. You will get a > "Sole completion" message. Press "space" or "M-b", or whatever, you will > get a message "aaaa:" which means that completion is repeated after any > other command. This is really bad, as my completion is calling an > external process and stalls emacs for a second, badly interfering with > the editing. Again, you're confused: the completion-at-point-functions do not perform completion, they just return the data about what completion table to use at point. >> 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. > Thanks for the pointer. I was not aware of this distinction. But why > would that make a difference? Because the completion table may or may not be used after being returned by completion-at-point-function. And it may be called with a different string than the one in the buffer. >>> 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. > I've written auto-complete support and emacs-24 completion at point > for R. And it turned out that these two are really distinct features. > One is fast, cache based and sloppy, as it should not interfere with > the editing. Another one is exact and might be very slow, because it > contacts the associated process. The TAB completions can afford to be > slow, as there is no editing. Interesting. So the completion candidates displayed in R-mode for auto-complete are different than the ones used for TAB? > Take auto-complete as an example. There are plenty of different > ac-sources, and users use whatever completion they want. >From what I can tell, this is largely because the major modes don't provide this info themselves yet. > Related topic. It would be great to have a separate "namespace" for all > buildin completions, or even a dedicated package. Then users and > developers can easily find buildin stuff. > For instance `completion-filename' instead of `comint-filename-completion', > `completion-etags' instead of `tags-completion-at-point-function' > etc. Auto-complete package is a good example here - all sources start > with "ac-source-". Hmm... more consistency in the naming might be good here, indeed. It's important to keep the "-" prefix since I don't want to consider all of this as part of Emacs's "core", but maybe we could settle on "-completion-at-point-function" or maybe something shorter than that. >>> 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. > To return the props it still must be called, right? Indeed if the > completion function were aware that it was called from popup, then it > can simply return nil to be skipped. But, AFAICT, this is not currently > the case. As mentioned, completion-point-functions should not work hard: it should just return the boundaries of what it would consider as "the text to complete if we were to complete it", and what code to use to get the completion candidates (again, in case we do decide to perform completion). For auto-complete, we might need to look at the completion candidates very often, in order to decide whether or not to popup a set of completions. But I'd hope that the `props' can provide the needed data (e.g. a predicate function to decide whether or not it's worth the trouble getting the list of candidates). Linking completion-at-point-functions and auto-complete is not done yet, clearly (and will probably also add more completion-metadata). Stefan