From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lluis Newsgroups: gmane.emacs.devel Subject: Re: Completions in Semantic Date: Tue, 27 Oct 2009 22:21:18 +0100 Message-ID: <20091027212118.GA25239@ginnungagap.pc.ac.upc.edu> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1256678590 17886 80.91.229.12 (27 Oct 2009 21:23:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Oct 2009 21:23:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 27 22:23:01 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 1N2tVM-00088Z-BC for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2009 22:23:00 +0100 Original-Received: from localhost ([127.0.0.1]:58606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2tVL-0005Nj-L1 for ged-emacs-devel@m.gmane.org; Tue, 27 Oct 2009 17:22:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2tTz-0003kX-Ln for emacs-devel@gnu.org; Tue, 27 Oct 2009 17:21:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2tTv-0003fK-Sg for emacs-devel@gnu.org; Tue, 27 Oct 2009 17:21:35 -0400 Original-Received: from [199.232.76.173] (port=49040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2tTv-0003f3-J6 for emacs-devel@gnu.org; Tue, 27 Oct 2009 17:21:31 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:54862) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1N2tTv-0004lQ-2v for emacs-devel@gnu.org; Tue, 27 Oct 2009 17:21:31 -0400 Original-Received: (qmail invoked by alias); 27 Oct 2009 21:21:27 -0000 Original-Received: from dync-30-245.ac.upc.edu (EHLO localhost) [147.83.30.245] by mail.gmx.net (mp039) with SMTP; 27 Oct 2009 22:21:27 +0100 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX1/IuCB2Yv3ICEtjwZW+ghfMq0BdZsN0JAIZmp7PeB KcU6F72LtE3Pby Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:116428 Archived-At: Sorry for the delay and the scarce response... too much work. El Thu, Oct 22, 2009 at 04:12:09PM -0400, Stefan Monnier ens deleità amb les següents paraules: > > I don't know about the features of current code, but I miss some > > features on some (if not all) the completion interfaces I've tested. > > So here's a list of (my) desired features (all of which should be > > configurable by the user): > > Sounds interesting, but I must be missing some context because there's > a lot of references I don't understand. Could you expand on them? Sure. > > - symbol name > > Of course, this is what already provides every completion UI > > No idea what you're talking about here. > > > - extra information > > This can be filled ub with symbol "metadata". Which metadata > > appears on the completion UI should be configurable by the user: > > - return type > > - arguments (type and/or name) > > - definition location (aka file) > > - short documentation > > - long documentation > > All this metadata should be located anywhere around the symbol name > > and/or the minibuffer (e.g., I think company-mode shows short > > documentation on minibuffer, until user presses F1, when full > > documentation is shown. Some metadata might be shown in the > > minibuffer after completion selection (e.g., prototype). > > Oh... wait, are you talking specifically about completion in code > buffers, so "symbol name" above referred to the ability to complete an > identifier? That's right. > 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). > 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. > > - 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). > > - 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). This could be achieved if completions where "complex objects", so each could describe what/where to show on the specific current completion UI, a "hover" callback (e.g. show short doc or symbol signature on minibuffer), and a selection callback (e.g., same possibilities as hover, plus the skeleton thing). Read you, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth