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: Completions in Semantic Date: Tue, 27 Oct 2009 20:56:40 -0400 Message-ID: References: <1255969613.6961.1056.camel@projectile.siege-engine.com> <1255980824.6961.1075.camel@projectile.siege-engine.com> <1255990628.6961.1084.camel@projectile.siege-engine.com> <1256070021.6961.1107.camel@projectile.siege-engine.com> <20091021105840.GD2964@ginnungagap.pc.ac.upc.edu> <20091027212118.GA25239@ginnungagap.pc.ac.upc.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256691465 19831 80.91.229.12 (28 Oct 2009 00:57:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Oct 2009 00:57:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lluis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 28 01:57:38 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N2wr0-0005no-Ry for ged-emacs-devel@m.gmane.org; Wed, 28 Oct 2009 01:57:35 +0100 Original-Received: from localhost ([127.0.0.1]:60129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2wr0-0008MC-CM for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2009 20:57:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2wqF-00082V-T9 for emacs-devel@gnu.org; Tue, 27 Oct 2009 20:56:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2wqB-000804-8V for emacs-devel@gnu.org; Tue, 27 Oct 2009 20:56:47 -0400 Original-Received: from [199.232.76.173] (port=46340 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2wqA-0007zx-UT for emacs-devel@gnu.org; Tue, 27 Oct 2009 20:56:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:2911 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2wqA-00039x-7Y for emacs-devel@gnu.org; Tue, 27 Oct 2009 20:56:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAPYz50pLd/xb/2dsb2JhbACBUNg1hD8Egl+FXQ X-IronPort-AV: E=Sophos;i="4.44,636,1249272000"; d="scan'208";a="48273151" Original-Received: from 75-119-252-91.dsl.teksavvy.com (HELO ceviche.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 27 Oct 2009 20:56:41 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id D85B370019; Tue, 27 Oct 2009 20:56:40 -0400 (EDT) In-Reply-To: <20091027212118.GA25239@ginnungagap.pc.ac.upc.edu> (Lluis's message of "Tue, 27 Oct 2009 22:21:18 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116430 Archived-At: >> As for this "extra info", I see what you mean, but usually completion >> involves several potential candidates, so listing them all plus all >> their info would take way too much space in general (if not, then >> something like completion-annotate-function should work). > What I described is similar to `completion-annotate-function', but > more flexible (prefixed in the symbol/identifier, postfixed; some in > overlay, some in minibuffer, etc). Right, so the question is: how should the generic code make such flexibility available (and conversely) how shojuld the client of the completion code be able to exploit/provide such flexibility. I'm very interested in adding such hooks into the completion code, but I haven't come up with any convincing idea of what they should look like (the closest I got is completion-annotate-function which is very limited). So suggestions are welcome (patches as well, of course, tho it's not crucial). >> So usually this extra info is provided outside of the completion >> functionality (e.g. via eldoc-mode or something similar). But, yes, >> I'd like to extend the *Completions* buffer so that you could ask for >> more info (either on all entries, or just on one at a time). > The key here is that completions do not necessarily have to go (only) > into the *Completions* buffer. Of course. company-mode is an obvious example. >> > - result narrowing >> > A-la company-mode. >> No idea to what this is referring. > Company-mode provides a binding that, given the current table of > possible completions, the user can narrow it through various > mechanisms (e.g., regexps). Would that be like IDO's C-SPC (aka ido-restrict-to-matches)? It shouldn't be too hard to add that to the default completion. Maybe even without having to change minibuffer.el (i.e. there should already be enough hooks for that). >> > - argument placeholders So that argument type and/or name is shown as >> > placeholders, such that the user simply TABs (or whatever) to fill-in >> > the blanks. >> >> Idem. Unless you mean something like skeletons/templates, but then >> I fail to see the connection with completion. > Completing a symbol triggers an arbitrary function, which could, for example: > - show symbol definition > - show short and/or extended documentation for symbol > - insert skeleton/template-like symbol definition (such that user simply > tabs to sellect next argument placeholder, which initially contains > argument name and/or type). That would be like the minibuffer-exit-hook, but for completion inside a normal buffer, right? That sounds like a good idea. Currently, figuring out when such "inline completion" ends is actually pretty difficult, but it's something very much needed. Stefan