Re: Is intellisense features integration in Emacs technically possible?

[Jorgen Schaefer]

On Thu, 23 Jan 2014 10:12:44 -0500
Stefan Monnier <address@hidden> 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 <symbol> 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.