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: Sun, 18 Mar 2012 20:53:11 -0400 Message-ID: References: <87haxoyff9.fsf@gmail.com> <87sjh8wdbw.fsf@gmail.com> <87haxmx0o7.fsf@gmail.com> <87d38aw8u1.fsf@gmail.com> <87ehspogzt.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1332118406 23382 80.91.229.3 (19 Mar 2012 00:53:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2012 00:53:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 01:53:22 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 1S9Qqf-0004Fy-5F for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2012 01:53:21 +0100 Original-Received: from localhost ([::1]:46735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9Qqe-0007nl-Ha for ged-emacs-devel@m.gmane.org; Sun, 18 Mar 2012 20:53:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9Qqb-0007nJ-UK for emacs-devel@gnu.org; Sun, 18 Mar 2012 20:53:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S9QqZ-00014W-UT for emacs-devel@gnu.org; Sun, 18 Mar 2012 20:53:17 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:35181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S9QqZ-00014E-Qb for emacs-devel@gnu.org; Sun, 18 Mar 2012 20:53:15 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q2J0rB5P008159; Sun, 18 Mar 2012 20:53:12 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 8949DAE148; Sun, 18 Mar 2012 20:53:11 -0400 (EDT) In-Reply-To: <87ehspogzt.fsf@gmail.com> (Vitalie Spinu's message of "Sun, 18 Mar 2012 20:18:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4165=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4165> : streams <739049> : uri <1085595> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:149124 Archived-At: >>> Yes, and no. What I meant is that the underlying mechanisms are very >>> different. 99.99% of the time the completion candidates are the same, >>> but there are objects which are not meaningful to cache, like arguments >>> of the user functions, or components of the recursive structures (lists, >>> environments, data.frames etc.). In this cases AC also calls the >>> process, and it's usually fast. But in some extreme corner cases, like >>> if user changed a function in an attached package, AC will still use the >>> cached version.' >> So, IIUC it would be perfectly OK for TAB completion to use the AC code. > Indeed, you could be right that always one-for-all completion function > might be made enough for the prefix completion. But I don't see how popup > menu can properly deal with partial completions for example, I'd expect popup menus wouldn't use the partial-completion style, but that's not a problem: the completion-styles only care about what to do once we have the completion data, whereas completion-at-point-function does not care about it at all since it only cares about providing that completion data. Every kind of completion UI can use its own (set of) completion style(s). If AC can be made to use a partial-completion style, great, but if not that's just as well. > or expansions a la yas. I guess you're referring to some part of yasnippet, but I don't know which part, nor why it is related to completion-at-point-functions. > So you would still need a separate list for those. As explained, partial-completion is another problem. As for abbrev-like "completion+expansion", I don't see why it can't work with AC (and if it can't work, the completion-at-point-function can return some data in its `props' making it clear it can't be used for AC). > And the old argument still stands - would the user like to have the same > redundant list of completion functions for C-M-i and popup menu? I don't see why not. Tho, for completions like etags-completion or dabbrev-completion, i.e. forms of completions which don't actually know whether the candidates they return are actually relevant at point, maybe we'd like to make exceptions (like we already do for dabbrev-completions which are bound to a special key rather than to TAB). >>>> 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. >>> I am a fan of the -completion postfix convention. It's easy to match in >>> apropos, anything or IDO regexp: comint-filename-completion, >>> tags-completion, imenu-completion, imenu-in-same-mode-completion, >>> words-in-same-buffer-commpletion etc. It can get pretty long by itself, >>> so a short postfix is better. >> But I suspect it will generate false positives because it's not >> specific enough. Maybe "-completion-data"? > Maybe -c-a-p, or -c-a-p-data? I used "-capf" within the code of completion-at-point, but I think it's too cryptic for use outside of that context. Stefan