From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?TGx1w61z?= Newsgroups: gmane.emacs.devel Subject: Re: Completions in Semantic Date: Sun, 01 Nov 2009 17:01:41 +0100 Message-ID: <868weq8c9m.wl%lluis@fulla.xlab.taz> References: <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> <1256696707.5333.214.camel@projectile.siege-engine.com> <20091029143811.GB25239@ginnungagap.pc.ac.upc.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1257091367 17403 80.91.229.12 (1 Nov 2009 16:02:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Nov 2009 16:02:47 +0000 (UTC) Cc: eric@siege-engine.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 01 17:02:40 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 1N4csR-0006aa-CK for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2009 17:02:00 +0100 Original-Received: from localhost ([127.0.0.1]:36201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4csQ-00081D-UK for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2009 11:01:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N4csL-00080K-US for emacs-devel@gnu.org; Sun, 01 Nov 2009 11:01:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N4csH-0007yr-5x for emacs-devel@gnu.org; Sun, 01 Nov 2009 11:01:53 -0500 Original-Received: from [199.232.76.173] (port=42284 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N4csG-0007yi-Uy for emacs-devel@gnu.org; Sun, 01 Nov 2009 11:01:49 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]:54958) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1N4csG-00045h-5w for emacs-devel@gnu.org; Sun, 01 Nov 2009 11:01:48 -0500 Original-Received: (qmail invoked by alias); 01 Nov 2009 16:01:44 -0000 Original-Received: from 156.pool85-61-226.dynamic.orange.es (EHLO localhost) [85.61.226.156] by mail.gmx.net (mp046) with SMTP; 01 Nov 2009 17:01:44 +0100 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX19EVLpo55tEkL4jbSnnWcYK2NlIZKslXHGbGk6sQx SDf1fxj3SGbMyu In-Reply-To: User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 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:116556 Archived-At: On Sat, 31 Oct 2009 16:18:17 -0400, Stefan Monnier wrote: [...] > > * Completion candidates > > ** Information Contains whatever information the system could gather > > about the symbol. When programming with semantic activated, this could > > be the semantic tag structure. > > If you don't know what that info is going to be, then it is useless in > the generic API since anybody using the generic API will expect to work > for any kind of candidate and so can't use this value since it has no > idea what it might be. I was thinking on a scenario where each completion source provides its own implementation of "Actions", and "Information" is thus not publicly visible but for the "Actions". > > ** Actions > > Various actions that can be applied on a candidate. > > This is basically the interface to view the candidate information. > > In the generic completion code, we currently have 4 actions: > test-completion, try-completion, all-completions, and the new > completion-boundaries (which in the case of function-name completion is > always trivial). > > For reasons of backward compatibility, it's difficult to add new actions > in the generic code (the new completion-boundaries is the first time we > add an action since ... before 1993), but one could easily imagine > adding actions for specific kinds of completions, which could then only > be used for completion tables that support those extra actions. So, any higher-level code could attach new actions as it sees fits. That's just what I was thinking about. > > **** get-return > > Return type of the candidate (only meaningful on programming candidates) > > **** get-arguments > > Arguments of the candidate (idem) > [...] > All this to say: if you conflate "get-return" and "get-arguments" > together, you'll get a system that will fit many more languages. You're right, this might be reduced to something like: - get-signature - get-definition The difference is that the first provides just a type signature, while the latter provides the whole definition (including the symbol name). But still it should be selectable whether you want argument names or just types. On the other hand, if the implementation of all the actions is provided by each completion source, the "get-*" actions simply are internal source-specific helpers, and thus out of the question. [...] > > *** insert-* > > Insert "something" at point (cannot think of use-cases where insertion takes > > place in other places other than point). > > I think side-effects have no business being here. Let the client code > do the insertion, and limit the candidate object to returning the > info necessary to figure out what to insert. I completely agree, but like show, this was more on the conceptual level where you can show and/or insert a specific candidate. > > * UI > > ** Types > > The completion-ui package has implementations for some (if not all) of them. > > The UI > > *** buffer > > Is the current *Completions* buffer. > > *** minibuffer > > The completion system used by, e.g., predictive-mode. > > *** overlay > > That's the one I prefer, see company-mode as an example. > > *** others > > There are many others, like menus, etc. > > Or icomplete-mode, yes. These seem to only affect > minibuffer-completion-help (the standard function that displays the list > of possible completions, usually in *Completions*). When I use > completion, I generally try to avoid getting to that point, tho. Sorry, I don't understand what you mean here. > This points to a more important aspect: when is this list displayed, > when is it updated, and when is it brought down. For each kind of > completion-list, those choices are not always the same > (e.g. icomplete-mode brings is up right away and updates it after each > keystroke, whereas what you call "buffer" only brings it up on a few > specific operations and only updates it on those same operations). > This behavior-variation depending on the display-style is something that > makes it trickier to write the generic code. Ok, I might say something totally stupid, but you just need to map the UI actions to specific keys, which can be selected by the user. And on the case of "continuous completion" the specific UI catches all keystrokes to issue the refresh action (the obvious option is to remap all keys, but I don't know how is this really implemented). > > *** start > > Start the completion process. E.g.: > > (show current-ui get-return get-name get-arguments) > > would show the full signature of a function. > > I don't understand it: when I start completion, I don't have any > function chosen yet (that's the whole reason for me to try to complete > it, usually), so there's no signature to show yet. Sorry, this was not detailed enough. What I meant is that you somehow tell the framework that each candidate must be shown as: return name arguments > > *** focus > > Let's the user "highlight" an entry of the possible candidates. It's the > > good old next/prev in an overlay UI. > > Focusing an element can trigger other actions. This will mainly be > > (show ...) > > The could be any of minibuffer, another buffer, tooltip, etc. > > Oh, so "show" is not a method that returns a string, it's a method that > has some side-effect that hopefully "shows" the candidate? That makes > more sense now. Yes, that's the idea I tried to express. > > *** completion-map > > Extra actions the user can trigger through keyboard when the completion UI > > is "active". > > E.g., i can focus to an interesting symbol and trigger > > (show some-buffer get-long-help) > > That might be tricky to support in a generic way, since depending on the > UI, it's not necessarily clear where the completion-map should be active > and with which other keybindings it might collide. As I see it, there are two types of interfaces: - in-buffer: this includes overlays, menus, etc. - in another buffer: the minibuffer is just a specific case of using another buffer for the completion UI. In the first case, once started, the user is interacting directly with the UI: moving focus, triggering "extra actions", etc. This UI can, in turn, modify the underlying buffer (partial completions, the user who keeps writing, etc.). On the second case, the user can indirectly interact with the UI through its current buffer (e.g., accept completion, stop completion, partial completion, etc.), or either switch to the completion buffer and trigger the rest of actions (e.g., move to a specific candidate and trigger the "show extended help" action). What I see more problematic is that some actions simply have no meaning in some specific candidate sources. E.g., yasnippet has no use for a "extended help" action. But at least, we can always ignore the action if the source/backend of a specific candidate provides no implementation for it. 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