jedi-vim: Python autocompletion inside Vim, now in maintenance mode

The problem jedi-vim solves, and who it is still for

Vim has no built-in understanding of Python. It can complete words from the current buffer, and that is roughly where it stops. jedi-vim exists to close that gap: it is a Vim binding to Jedi, the autocompletion library, and it brings completion, goto, documentation and renaming into the editor without requiring a language server.

The audience is narrow and specific. You write Python, you already live in Vim or Neovim, and you are willing to install a plugin plus its Python dependency by hand. The README's own feature list is the honest scope: completion on Ctrl+Space, goto assignment on <leader>g, goto definition on <leader>d, goto typing stub on <leader>s, documentation on K, renaming on <leader>r, usages on <leader>n, and :Pyimport for opening a module such as os.

The README opens with a warning rather than a pitch. It states that jedi-vim has been superseded by a combination of LSP and Zuban with it, advises people to use Zuban because it fixes many of Jedi's typing issues and is 10x-100x faster, and says jedi-vim is in maintenance mode and new features will likely not be added. That sentence should shape how you read everything else on this page. You are evaluating a plugin the maintainer has told you not to start with.

How jedi-vim talks to Jedi and to your buffer

The architecture is a binding, not a server. Vim embeds a Python interpreter, and jedi-vim's Python code lives under pythonx/ in the repository, invoked through that embedded interpreter. Jedi does the analysis of your Python source; jedi-vim translates the results into Vim buffers, splits, tabs and popups.

That translation layer is where the plugin's own configuration lives. Several settings decide where a jump lands: g:jedi#use_tabs_not_buffers switches navigation to tabs, and g:jedi#use_splits_not_buffers accepts left, right, top, bottom or winwidth to open a split in a chosen direction. Others decide when the menu appears. Jedi starts completion automatically when you type a dot, for example after str., and g:jedi#popup_on_dot = 0 turns that off. g:jedi#popup_select_first controls whether the first entry is preselected, which the README describes as usually saving one keypress.

The most interesting design choice is call signatures. g:jedi#show_call_signatures can render the signature as a popup in the buffer, which the README says is set to 1 by default with the conceal feature and 2 otherwise, or in Vim's command line aligned with the call. The README is unusually candid here: the in-buffer popup is easier to refer to but is described as a hack with many drawbacks since it changes the buffer's contents, while the command-line variant can improve the integrity of Vim's undo history. That is a real trade-off between readability and undo behaviour, and it is one of the few places where the documentation tells you the cost of a default.

Installing jedi-vim and running a first completion

Check the interpreter requirement before anything else. Inside Vim, run the command the README gives. If it prints a Python 3 version, your Vim was compiled with +python3 and can host the plugin.

:python3 import sys; print(sys.version)

Neovim takes a different route. It needs a Python environment with pynvim installed, and the README gives this command and a health check to confirm the setup.

pip install pynvim
:checkhealth provider.python

For installation, the README recommends a plugin manager and warns against installing Jedi separately with pip, because that can cause problems inside virtual environments. The Pathogen example clones the repository recursively so the Jedi submodule comes along.

git clone --recursive https://github.com/davidhalter/jedi-vim.git ~/.vim/bundle/jedi-vim

With Vundle the README asks for a single line in ~/.vimrc instead.

Plugin 'davidhalter/jedi-vim'

If you clone without --recursive, the README's fix is to initialize the submodule inside the jedi-vim repository.

git submodule update --init --recursive

After restarting Vim, open a Python file and press Ctrl+Space. You should see a completion menu; typing str. should also trigger it unless you disabled g:jedi#popup_on_dot. Press K on a name to see documentation, and use :Pyimport os to confirm the module-opening command works. Distribution packages exist for Arch Linux as vim-jedi, Debian and Ubuntu as vim-python-jedi, and Fedora as vim-jedi, but the README notes those versions may be quite old compared to the Git checkout.

Where jedi-vim breaks or becomes the wrong choice

The first limitation is stated by the project itself. The README says Jedi has issues with typing and that Zuban fixes a lot of them while being 10x-100x faster. If your codebase leans on annotations and you expect completion to respect them precisely, the analysis engine underneath jedi-vim is the weak point, and no amount of Vim configuration changes that.

The second is maintenance. The README says jedi-vim is in maintenance mode and that new features will likely not be added. The last push to the repository was on 2026-06-16, so the code is not abandoned, but the direction of travel is away from this plugin. Adopting it means adopting a fixed feature set.

The third is a plugin conflict you have to resolve yourself. The README states that python-mode seems to conflict with jedi-vim and that you should disable it before enabling jedi-vim. If python-mode is part of your setup, this is not a drop-in addition.

The fourth is a platform detail that affects behaviour rather than installation. To get the full feature set, the README asks for Vim >= 7.3 compiled with +conceal, which it notes is not the case on some platforms including OS X. Without it, the parameter recommendation list may not appear when you type an open bracket after a function name. The plugin still loads; one feature quietly does not.

Finally, the README does not document rollback or an uninstall path. Removing the plugin directory and the .vimrc settings is the obvious move, but the project does not describe it, so treat cleanup as your own responsibility.

jedi-vim versus YouCompleteMe and the LSP route

The comparison worth making is with YouCompleteMe, which people search for alongside jedi-vim. Both are Vim completion plugins for Python, but they sit at different layers. jedi-vim is a thin binding: Jedi parses and analyses your Python, and the plugin renders the result. YouCompleteMe is a completion engine with its own server architecture and its own build step, and it can drive multiple language backends rather than one.

The practical difference is what you install and what you maintain. jedi-vim needs a Vim with +python3, or a Neovim with pynvim, plus the Jedi submodule, and that is the whole dependency chain. A language-server setup needs a client plugin and a separate server process, which is more moving parts but also the route the README itself endorses when it says jedi-vim has been superseded by a combination of LSP and Zuban. If your reason for considering jedi-vim is that you want the smallest possible Python completion setup in Vim, it still wins on that single axis. If you want the stack the maintainer points at, it loses.

Maintenance cost, testing and the MIT licence

The repository's Makefile shows how the project is checked. The test target runs pytest, and test_nvim runs the same suite with VSPEC_VIM=nvim, so both Vim and Neovim paths are exercised. There is also a check target that depends on vint and flake8, installed into a build virtual environment at build/venv with pinned versions: vim-vint==0.3.21 and flake8==3.7.8. Linting runs over the after, autoload, ftplugin and plugin directories, and flake8 runs over pythonx/jedi_*.py. If you fork or patch jedi-vim, those are the commands to reproduce locally.

Upgrade cost is low in one sense and fixed in another. The plugin is a git checkout, so updating means pulling and refreshing the submodule; nothing new is promised on top. If you installed the distribution package instead, the README's own note applies: it may be quite old compared to the Git version.

jedi-vim is MIT licensed, and the repository carries the licence in LICENSE.txt. That is a permissive licence, which generally means you can reuse and redistribute the code with the licence notice preserved; the exact obligations and how they interact with your product are a question for your own legal review, not something this article can settle.

Editorial conclusion

Use jedi-vim if you want Python completion inside a Vim you already configure by hand, you are comfortable with git submodules, and you accept that the project is in maintenance mode with no new features planned. Do not adopt it if you need type-checker-grade correctness on modern annotated code, or if you want a completion stack that is still evolving; the README itself points to Zuban for that. Before committing, verify three things on your machine: that your Vim reports +python3 via :python3 import sys; print(sys.version), that Neovim passes :checkhealth provider.python after pip install pynvim, and that python-mode is not enabled in your plugin set, because the README states it conflicts with jedi-vim.

Frequently asked questions

Official sources

1. davidhalter/jedi-vim on GitHub
2. Issues
3. License: MIT
4. README