vim-jukit keeps a Jupyter-style notebook inside a Neovim buffer

The unit of work in vim-jukit is a cell, not a file

vim-jukit is a Vim and Neovim plugin built for people who want a REPL with more structure than a bare prompt. The README lists the feature set as sending code to a split window running your preferred shell, structuring code with cell markers and using cell operations, dedicated markdown cells with markdown syntax, converting between .ipynb notebooks and scripts in both directions, displaying plots inside the terminal on kitty or iTerm2 with tmux when using matplotlib, and saving cell outputs from an IPython shell so they can be shown again on demand. The notebook model is the important part. Instead of treating a Python file as one undifferentiated buffer, the plugin lets you carve it into cells with markers, move those cells around, split them, merge them back, and mark some of them as prose rather than code. The plugin is written in Vim Script and the repository is laid out with a plugin directory, an autoload directory and a helpers directory, which is the standard shape for a Vim plugin that keeps most logic out of the startup path.

Code reaches the interpreter through a split window, not through a pipe

The execution model is worth understanding, because it explains both the plugin's appeal and its limits. Rather than embedding an interpreter inside the editor and talking to it over a pipe, vim-jukit sends the current cell to a split window running your preferred shell. You are then talking to a real shell in a real pane, so the shell you use is yours, with your aliases, your environment and your history. The README shows this as one of the previewed capabilities, sending code to the terminal. The trade off is that the plugin is not driving a language kernel in a controlled way, so the feedback loop depends on how your shell behaves when text arrives at it. For IPython specifically the plugin adds something extra: it can save outputs of cell executions and display those saved outputs on demand in a dedicated split window. That is a different model from Jupyter, where outputs are stored in the notebook document. Here the outputs are captured from the shell session and can be replayed into a viewer window later.

Installation is a plugin directory plus three pinned Python packages

The visible documentation focuses on requirements rather than on a package manager command, so the practical installation path is the plain Vim way: place the plugin so that its plugin and autoload directories are on your runtime path, then install the Python side. The repository ships a requirements file with three pinned versions, which is worth honouring exactly on a first attempt.

ipython==8.8.0
matplotlib==3.6.2
nbconvert==7.2.7

Pinning matters here more than usual. The plugin calls into IPython for output capture and uses nbconvert for the notebook conversion path, and the README separately states the requirements as IPython version 7.3.0 or newer and matplotlib version 3.4.0 or newer. The editor side has its own floors: Vim version 8.2 or newer, or Neovim version 0.4 or newer, and in both cases python3 support inside the editor, which the README tells you to confirm by echoing the has('python3') check from the command line. If that check returns 0, the plugin will not run and no amount of Python package work will change that.

Inline plotting is a kitty feature and an experiment everywhere else

Displaying matplotlib plots inside the terminal is the feature that makes this plugin distinct from a plain runner, and it is also the most environment dependent part of it. The README requires kitty version 0.22 or newer, remote control enabled in the kitty configuration, and ImageMagick installed for showing plots. For Neovim under kitty, kitty must additionally be launched with the listen-on option and an address to listen on, and the README explains that different kitty instances need different addresses if you want to send code to splits in more than one of them at a time. The iTerm2 plus tmux route is labelled experimental and was tested on iTerm2 Build 3.4.15 with tmux version 3.2a, with the author warning that it may not work with a different tmux version. So the honest summary is that in terminal plotting is a first class path on kitty and a best effort path on iTerm2 with tmux.

Überzug can replace the split window, at the cost of an unmaintained package

There is a second way to show captured output: instead of printing it in a split window, the plugin can display saved outputs as images in the terminal using überzug. The README marks this option as experimental. The dependency chain behind it is the part to weigh. The listed Python packages are pillow, beautifulsoup4, numpy and nbconvert version 6.4.4 or newer, and the required command line tools include imagemagick and cutycapt, with wkhtmltopdf named as an alternative in the same line. Überzug itself is the problem: the README states plainly that the package is no longer maintained and is available via pip, so it has to be installed manually by cloning the 18.1.9 branch of the seebye/ueberzug repository and running its setup script.

Installing an unmaintained package from a pinned branch into a Python environment on a developer machine is a decision with a cost attached, and the plugin treats this route as optional while the split window route stays available.

Notebook conversion is a file transform, not a Jupyter client

The ipynb story has two halves. Converting in both directions between notebooks and scripts is presented as a headline capability and is what a team sharing notebooks with Jupyter users would reach for. The README also lists previewing a file as PDF or HTML. What the plugin is not is a Jupyter client. There is no kernel management, no cell queue, no execution order bookkeeping, and no browser based rendering of the notebook document. Instead, the plugin keeps the notebook structure as text in a buffer with markers, sends cells to a shell, and captures what comes back. The output saving feature, which stores cell outputs from an IPython shell and shows them on demand in a dedicated split window, sits closer to a log of the session than to a stored notebook state. For someone who wants their files to remain plain scripts, that is the right shape. For someone who wants a faithful Jupyter experience with rich outputs embedded in the document, the gap between the two tools is large.

The maintainer says outright that time is the limiting factor

Two of the README's requirement sections carry an unusual candour about platform support. For Windows, the note says the author is not a Windows user, that a working version was achieved at one point, and that if you have problems you should be prepared to solve them yourself because debugging from another platform takes time and the author has limited time for open source projects. The same wording appears for the iTerm2 plus tmux path. Elsewhere the README notes that kitty users can optionally open splits in separate OS windows, which is useful with multiple monitors. The project is MIT licensed, and the maintenance record is thin in the way a solo maintained project tends to be: the last push was on 2026-06-10, while the tagged releases stop at v1.4.1 from 2023-02-26, with v1.4.0 from December 2022 and v1.3.4 from November 2022 before it. There is no stable release newer than the 2023 tag, so an adopter is effectively running whatever sits on the default branch.

Editorial conclusion

vim-jukit suits Vim or Neovim users who already work in IPython and want notebook structure and cell execution without leaving the editor, particularly on kitty where in terminal matplotlib plots work. It does not suit someone who wants a maintained Jupyter front end, since the latest tagged release is v1.4.1 from 2023-02-26 while the last push was on 2026-06-10, and it does not suit a team that needs the same experience on every platform, because the author states plainly that the Windows and iTerm2 plus tmux paths were only made to work once and that debugging them from the maintainer's platform is slow. Before adopting it, check three things: that your Vim has python3 support as the requirements demand, that the pinned packages in requirements.txt, ipython 8.8.0, matplotlib 3.6.2 and nbconvert 7.2.7, install cleanly in your environment, and that the ipynb conversion path in your workflow handles the cell markers the plugin expects.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. luk400/vim-jukit on GitHub
4. README
5. Releases