From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Thu, 23 Jan 2014 21:56:56 +0100 Message-ID: <20140123215656.30bf63b8@forcix.kollektiv-hamburg.de> References: <1390269670.2888.14.camel@localhost.localdomain> <83zjmpf80o.fsf@gnu.org> <877g9shqms.fsf@newcastle.ac.uk> <20140122194930.49ba60be@forcix.kollektiv-hamburg.de> <87fvoedebx.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390510634 3729 80.91.229.3 (23 Jan 2014 20:57:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 20:57:14 +0000 (UTC) Cc: phillip.lord@newcastle.ac.uk, Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 23 21:57:20 2014 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 1W6RKt-00078m-Ay for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 21:57:15 +0100 Original-Received: from localhost ([::1]:43212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6RKs-0007Sd-Sj for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 15:57:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6RKl-0007SB-M6 for emacs-devel@gnu.org; Thu, 23 Jan 2014 15:57:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6RKg-0003pl-SU for emacs-devel@gnu.org; Thu, 23 Jan 2014 15:57:07 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:56452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6RKg-0003ph-I7 for emacs-devel@gnu.org; Thu, 23 Jan 2014 15:57:02 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id EA37020136B; Thu, 23 Jan 2014 21:57:00 +0100 (CET) Original-Received: from forcix.kollektiv-hamburg.de (x2f0f3d1.dyn.telefonica.de [2.240.243.209]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 32303201367; Thu, 23 Jan 2014 21:56:58 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 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:168982 Archived-At: On Thu, 23 Jan 2014 10:12:44 -0500 Stefan Monnier wrote: > >> It's mainly a common interface for such external programs so that > >> we can add more languages more easily. The current effort of > >> unifying the completion interface as well as supporting company > >> mode as a front-end is going a great deal forward in that. > > I'm not convinced that a single interface would work; again, using > > clojure as example, this has moved away from a single interface in > > Emacs (i.e. slime/swank) and toward a single interface for Clojure > > (so that the Clojure side offers a single server, for different > > editors). > > He's not advocating a common interface for all languages at the level > where Emacs interacts with the external process. He's only advocating > a common interface at the Elisp level so that the major mode only > needs to adapt this interface to the underlying external process's own > interface (or to the Elisp code that does the parsing if it's > implemented in Elisp). This, exactly. Let me see if I can elaborate. There are currently four main RPC calls that I use Python for. They have more or less good support on the Emacs side. Eldoc ----- Eldoc is a great example. In its basic form, it's exactly what I want: Your major mode sets a variable - `eldoc-documentation-function' - to a function that simply returns the documentation to show. Simple programming interface to implement, and all modes using it provide a unified user interface. There are only two things this is lacking for me right now. First, it could be improved with more output options. For example, emacs-jedi.el provides popup-style display for signatures: http://farm3.staticflickr.com/2845/8793986161_e1c58607f0_o.png Allowing the user to customize eldoc to use one or the other, and then having that user's preference take effect in all programming modes, would be excellent. Second, and this is a recurring thing for Emacs APIs, it does not handle asynchronous calls too well. One of the nice things about using an external process to do the heavy munging of source code is that you can ignore Emacs single-threadedness and simply keep accepting user input until the response is there. I currently work around this by returning the old eldoc string and calling `eldoc-message' in the asynchronous callback, but I have no idea if eldoc actually expects this. In the case of auto-completion, this is a lot more complicated. Completion ----------- The main topic being argued here. I'm currently using auto-complete.el, but I hope to eventually use `completion-at-point-functions' once company-mode is integrated. I'm not sure it will have all the features I'd like, but those likely could be implemented. Important features I haven't seen for c-a-p-f yet: Provide an overlay of the most likely completion candidate while you type for quick completion with TAB; add annotations to completion candidates, for example to indicate symbol type; ability to provide documentation for a completion candidate so that can be shown while browsing candidates. Examples (using auto-complete and elpy): Default completion overlay: http://i.imgur.com/0Fml2dd.png Some annotations and documentation: http://i.imgur.com/Vs7WKRa.png More annotations (using emacs-jedi): http://farm9.staticflickr.com/8261/8804536872_8d266b88ed_o.png Oh, and support for getting completion candidates asynchronously. This is quite tricky, as the user might have moved point in the time the candidates were returned, and it's not always necessary to re-request the candidates then. auto-complete.el handles this "mostly ok" using an init function and caching the response, but has some hard to trace problems. Find Definition --------------- This is what is bound to M-. and M-* in some modes. Providing a single variable to put a function in that goes to definition at point which is then called by M-., instead of hard-coding it to `find-tag', would go a long way. Especially when the definition also keeps track of movement and adds that to the movement ring for M-* by itself. Hell, we could even make emacs-lisp-mode provide that and not force the user to use C-h f all the time to go to the definition! :o) Show Documentation ------------------ C-h f does this for Emacs Lisp, and I don't think there's a standard key binding for it. Again, a simple variable that can be changed to return the docstring for the symbol at point which then shows a help buffer like C-h f does would be nice as a standard interface. On the topic of a "unified RPC interface", it does grate me a bit that every mode implements its own RPC with a major language (elpy implements a simple JSON-RPC one, emacs-jedi uses the elaborate EPC library, ropemacs uses Pymacs which uses a very idiosyncratic protocol, slime does the swank stuff, clojure apparently has its own API now, etc. etc.), but I'm not sure if that's a solvable problem. Choice of the RPC mechanism depends as much on Emacs as it does on the capabilities of the language being talked to. The JSON-RPC code in elpy is a total of 450 lines, both the Emacs Lisp as well as the Python side, including docstrings and comments, so not having a standard one is not really a huge problem. Having a simple interface on the Emacs side that can be used by major modes so that Emacs presents a unified interface to the user with minimal effort of reimplementing the wheel every time would be very useful, though, and quite doable. Once we have that, it'd be possible to provide one or more "standard RPC mechanisms" that simply plug in to that API and talk to the compliant subprocess, but that's not nearly as important right now. I hope the above explains my remark about the "single interface" in Emacs. :-) Regards, Jorgen PS. Please do not think that the above is meant as a request that "someone should implement this"; it's just my thoughts on the topic of whether intellisense/IDE features integration in Emacs is possible, and how it could be done. If it happens, great. If not, ok. If it annoys me too much, I'll work on that eventually, if and when I find the time.