Vim-R drives the R console from the editor, and its author has moved on

Read the notes before you install it

The first line of the README says that Vim-R is superseded by R.nvim, and the next lines explain what that means in practice. For Neovim users, this plugin is superseded by R.nvim. The author's own note is more pointed. He no longer uses Vim-R and will only fix newly reported bugs if they are serious enough to prevent its use, and he will not fix minor bugs. Anyone who wants to contribute to an actively maintained project is pointed to the jcfaria fork of the same plugin, with the link given in the same paragraph. That is a rare and useful combination, a maintainer telling you both that this version is finished and where the moving version is. It also explains the shape of the release history, where 1.0.0 was published on 2026-05-02 after 0.9.21 in April 2025 and 0.9.20 in March 2024, with the last push to the repository on 2026-09-14. A 1.0.0 in a maintenance-mode plugin is a statement that the code is complete rather than that it is evolving.

Three routes to the R console

The core of the plugin is a diagram of the communication between Vim and R, and it comes down to the fact that a command you trigger in the editor has to be pasted into the R console. There are three different ways of sending those commands, and which one applies depends on where you run R. When you run R in a Vim built-in terminal, the function chansend() is used to send code to the R console. When you run R in an external terminal emulator, Tmux is used to send the commands. And on Windows, Vim-R can send a message to R through vimcom, which forwards the command to the R console. The black arrows in the diagram are the commands you trigger and that you can see being pasted into the console, so the mechanism is visible rather than hidden, and the consequence is that the behaviour of your setup depends on which of the three routes your operating system and habits allow. Vim's built-in terminal support is what makes the first route possible.

vimrserver is a TCP server run as a Vim job

The third route, the one that works on Windows, is the most interesting piece of engineering. The R package vimcom includes an application called vimrserver, which is never used by R itself but is run as a Vim job, and the communication between vimrserver and Vim goes through that job's standard input and output. The application runs a TCP server, and when vimcom is loaded it immediately starts a TCP client that connects to vimrserver. So there are two processes and a socket, and the editor side talks to the R side over TCP while the job plumbing keeps the lifetime tied to the editor session. The green arrows in the diagram are the job communication and the red arrows are the TCP connection, and the split is what allows a message to travel from inside an R session back to the editor. Most of the information between the two sides travels over that TCP connection, with temporary files used in only a few cases, which is a good trade because a socket is a cleaner channel than a file that has to be polled.

The commands that never reach the console

A useful detail in the documentation is which commands do not go to the R console at all, because their results are seen in the editor itself. Those are the commands that do omnicompletion of names of objects and function arguments, start and manipulate the Object Browser with the key mappings for opening it, setting it and removing it, call R help with the help key or the help command, insert the output of an R command with the insert command, and format selected text with the format command. Completion and help in particular are the reason to reach for this plugin at all, since they are the two things that are painful over a plain console connection, and both of them need a round trip to the R session without disturbing what is on the console. The Object Browser is the third such feature, and it is a live view of the objects in the session, which is the R equivalent of a workspace pane.

R pushes changes back to the editor

The traffic is not one way. When new objects are created or new libraries are loaded, vimcom sends messages that tell the editor to update the Object Browser, update the syntax highlight to include newly loaded libraries, and open the PDF output after knitting an Rnoweb file and compiling the LaTeX result. The first two are quality of life features that only work because the editor is told about a state change rather than having to guess it, so a library you load in the console immediately gets R syntax highlighting in any script you open afterwards. The third is the one that is genuinely useful for document work, because knitting an Rnoweb file and compiling the LaTeX result produces a PDF, and having that PDF open itself when the build finishes saves the round trip of finding the file and opening it. The cost of the whole design is that the R side has to be running and connected, so the editor is not merely a text buffer for the R session, it is a second front end for it.

The repository layout and what to look at first

The top level of the repository is the standard Vim plugin layout, and reading it tells you where to look for something. There is ftdetect/ for file type detection, so that a .R file is recognised, ftplugin/ for the file type plugin, syntax/ for the R syntax highlighting, and hooks/ for the autocommand hooks. There is an R/ directory holding the R side of the integration, which is where the vimcom package lives, and a doc/ directory with the Vim-R.txt help file that the README points you to for the installation and use sections. The vimrcom.svg file at the top level is the communication diagram, kept next to the README because it is the fastest way to understand what the plugin does. The licence is GPL-2.0, the default branch is master, and the project is not archived. If you are starting from nothing, the order that makes sense is the help file for the commands, then the diagram for the model, then the R directory if you want to know what the server side is doing.

Editorial conclusion

Vim-R fits a Vim user on a terminal whose R work still runs through the console and who wants omnicompletion, an object browser and formatted output without leaving the editor. It does not fit a Neovim user, because the plugin is superseded by R.nvim for that editor, and it does not fit anyone who wants a maintained project, because the original author states he no longer uses the plugin and will only fix serious bugs, and points to the jcfaria fork for active development. Before you install it, read the notes at the top of the README, because the maintenance status is the first fact in it, and if you rely on the Object Browser or on the automatic PDF preview after knitting an Rnoweb file, check that path works for your setup since those depend on the vimcom side rather than on the Vim script alone.

Frequently asked questions

Official sources

1. Issues
2. jalvesaq/Vim-R on GitHub
3. License: GPL-2.0
4. README
5. Releases