Skip to content

Jedi: A completion library for Python

by mickey on January 10th, 2013

If you’re using Python with Emacs (using one of several competing, incompatible, and slightly different modes) you are used to a pretty… bare-bones experience: no completion; semi-functional dynamic docstring support; and little in the way of two-way communication between Python and Emacs.

Enter Jedi, a completion library. Yes, Jedi, an editor-agnostic library that publishes auto completion, docstring support, and more. Excellent.

I’ve experimented with Pymacs — an interesting science project that adds “Python-like” support Emacs, so you can avoid interacting with Elisp, except not really — rope, and ropemacs and they were… disappointing. Slow, crash-prone, obtuse and impossible to extend. So I never really used them, and lived without completion or, well, much of anything beyond the REPL and my own handcrafted modifications.

The other alternative is the 600 lbs gorilla, CEDET, and its incomplete Python support, but that’s no good either.

Imagine my surprise, after fidgeting with the dependencies for both Jedi and Jedi.el, the Emacs library for Jedi, that it… works! And it’s good! It’s up-and-coming, I should say, but perfectly usable; it doesn’t get in my way, it’s got some crazy deferreds library it depends on for asynchronous, non-blocking querying of Jedi, but that bit works great — no input lag at all.

It seems to resolve, simplistically (which is good), as many assignments and method calls as one can reasonably expect from a non-evaluating, statically analyzing Python completion library.

Functioning Auto Complete in a Python buffer

The Jedi.el module also Just Works with the excellent auto-complete library, as you can see in the picture above.

Aside from completion, it also offers “find symbol definition at point” (a la TAGS, but not crap) and Jedi.el sensibly binds it to C-. by default. It also has a “related names” functionality, tracking down same-named identifiers in other modules; it uses Anything (now Helm) to display the results, and it is bound to C-c r. And finally, it can show the documentation for the identifier at point (be it a class or function) with C-c d. Useful.

I haven’t used Jedi and Jedi.el long enough to really get to know it, but I’m probably going to extend Jedi.el so it uses eldoc-mode for displaying the function parameters; it’s also a bit rough around the edges, and I may want to tweak certain things to my liking, but overall: huge success!

I highly recommend you give Jedi and Jedi.el a try!

18 Comments
  1. Thanks for the blog post. I am the author of Jedi.el. It’s good to know you like it!

    Just a minor point: Jedi the Python library does not have RPC mechanism. In fact, vim plugin does not use RPC server. I use S-expression based RPC [1] to use Jedi from Emacs. I could use Pymacs but I thought auto-completion should not block user commands.

    [1] https://github.com/tkf/python-epc

    • mickey permalink

      Thank you for making it! I’ve updated the blog post.

      • What I meant to say is that RPC mechanism is outside of the Jedi the Python library by @davidhalter. From the way you write it, I think it sounds like Jedi has built-in RPC server, which is not the case. I think you can just drop the part “, using an s-exp-based RPC server mechanism”.

        It’s not a big deal for most of Jedi.el users. I just thought it’s better to clarify it.

        • mickey permalink

          Much appreciated; thought Jedi had it built in. I’ve elided that part of the sentence entirely :)

          Thanks for the correction and your hard work on this!

    • John Bash permalink

      Thanks Takafumi. Are there any features in python.el or python-mode.el that that you would like to port to emacs-Jedi? Is there anything specifically that you think is still missing in emacs-Jedi?

      • mickey permalink

        Eldoc-mode and better integration with imenu spring to my mind.

        IMenu support should be easy enough to add, and I have code of my own that uses the same parsing engine Pylint uses to rip out class/function names from the file you’re in.

        • (setq jedi:tooltip-method nil) then you have eldoc-like signature hint:
          http://tkf.github.com/emacs-jedi/#jedi:tooltip-method

          Yes, Jedi lacks imenu support. But I think both python.el and python-mode.el have the one and it works OK. It is true that if you can use Python’s AST module you can get more accurate result. If you want it, I think the best move is to send the feature request to Jedi (the Python library, not Emacs binding, as it is not possible to support it unless the Python library has it).

          • mickey permalink

            Nice to know about the tooltip mode, Takafumi. I might write some actual eldoc-mode support as I try to reuse existing components.

            The python.el imenu doesn’t refresh very well, but that could just be the version I have. I don’t use the AST module as it expects functioning python code and barks if it’s not syntactically correct. I use Pylints’ version as it works with “broken” Python, a state my python code may very well be in.

          • I think Jedi has parser for broken source. So I guess Jedi is a good place to support imenu.

            BTW, if you have trouble with Pymacs but still want rope, check https://github.com/abingham/traad. It’s another rope client but does not depend on Pymacs.

  2. PuercoPop permalink

    The only issue I found with jedi is that I couldn’t get it to play well with virtual env, but maybe it was more to my own shortcoming than jedi’s

    • mickey permalink

      Hmm. It seems to work OK on my end. Let me double check my settings as I have some gnarly virtualenv hackery going on that may account for why it’s working.

    • If you have some trouble, file an issue in the github issue tracker.

      Note that Jedi.el needs VIRTUAL_ENV to be set to use virtualenv. Also, Python version you are using for the virtualenv must be the same one as the one you are using for Jedi EPC server.

  3. John Bash permalink

    How does Jedi compare to python.el and python-mode.el? It would be great to have an in-depth (maybe side-by-side) study of the alternatives for Python users at some point.

    • mickey permalink

      Well, jedi does not replace python.el/python-mode.el — perhaps I should clarify that in my opening statement — as it is merely an addition to python, rather than a replacement for it.

      • John Bash permalink

        I see. But we don’t really need python-mode.el to run Emacs-jedi, correct? It looks like both packages overlap in functionality quite a bit.

        • It is true that Jedi.el does not require python-mode (python.el or python-mode.el), but you don’t want to use it without python-mode. For example, Jedi.el does not provide syntax highlighting. Jedi.el provides a minor mode where python-mode is a major mode.

          I don’t think there is major overlap between Jedi.el and python-mode. python.el implemented in pure Emacs Lisp so there is no way to access Python functionality except for very simple Python shell integration.

          What still lacks with python-mode + Jedi is better REPL integration. If you want more advanced one than plain Python shell in python-mode, try my other project called EIN:
          https://github.com/tkf/emacs-ipython-notebook#readme

  4. There’s already some work done on integrating jedi with eldoc: https://github.com/emacsmirror/jedi-eldoc

Leave a Reply

Note: XHTML is allowed. Your email address will never be published.

Subscribe to this comment feed via RSS