A Python-first Vim configuration built on Vundle, NERDTree and a source-built Docker image

The install path starts with a Vim binary that has Python support

This repository holds a dotfiles setup, not the editor. The stated aim is more Python, JavaScript, Vue.js, Go and Markdown support, with Haskell, Ruby and C or C++ planned for later. The first gate is unusual for a Vim config: you need a Vim compiled with Python support, and the check is `vim --version | grep +python`. If that returns nothing, the Python-side tooling in this setup will not behave as intended.

After that come the platform dependencies. On Debian and Ubuntu the listed packages are python, vim, exuberant-ctags and git, followed by the Python linters pep8, flake8, pyflakes and isort installed through pip. RedHat and CentOS get the same set through yum, with a warning that CentOS 6.7 ships Python 2.6 and that Python 2.7 is recommended instead. On macOS the instructions install python, vim and git with brew, and then build exuberant ctags 5.8 from a SourceForge tarball with configure, make and make install, because the install steps do not treat a ctags package as sufficient on that platform.

The configuration itself is a single file. The vimrc at the repository root is copied to the user home directory as .vimrc, and Vundle takes over from there. Nothing in the setup touches a system-wide Vim, so the change is reversible by deleting that file.

Vundle clones the whole plugin set on the first launch

Plugin management is delegated to Vundle, and this is the single most important structural fact about the project. Every plugin declared in the vimrc is downloaded into the .vim directory under a bundle folder, by default. The install instructions ask you to keep that directory clean before first use, because Vundle assumes it owns the contents. Installing plugins triggers a git clone operation, and searching for plugins additionally needs curl present on the machine.

The plugin block in the vimrc is where the choices are visible:

Plugin 'gmarik/vundle'
Plugin 'scrooloose/nerdtree'
Plugin 'scrooloose/nerdcommenter'
Plugin 'majutsushi/tagbar'
Plugin 'kien/ctrlp.vim'
Plugin 'motemen/git-vim'

The exposed commands are the standard Vundle set. :PluginList lists everything currently installed, :PluginInstall installs or updates a plugin, :PluginSearch searches by keyword, :PluginClean removes unused plugins and :PluginUpdate refreshes what is already there. The exclamation mark in the command table marks the variants that skip confirmation prompts.

A fragment of the plugin block shows the character of the setup: a file browser, a commenter, a class and module browser, a fuzzy finder for code and files, a command palette extension, an emmet plugin for markup expansion, a git integration layer and a tab list panel. The configuration is a curated set of well-known Vim plugins rather than a set of custom mappings, which means a reader inherits both the conveniences and the rough edges of that selection.

NERDTree opens on VimEnter and closes itself when alone

The file browser is NERDTree, and the vimrc drives it with two autocommands rather than a single toggle. One hook fires on VimEnter and opens the tree when Vim was started without a file argument. A second hook watches for the case where the tree is the only window left and closes it, so the tree does not occupy the screen after you open a file from it. The mapping layer adds a function key to toggle the tree and a two-character key that opens the tree with the current file already selected.

The relevant lines from the configuration are:

autocmd vimenter * if !argc() | NERDTree | endif
map <F3> :NERDTreeToggle<CR>
nmap ,t :NERDTreeFind<CR>
let NERDTreeIgnore = ['\.pyc$', '\.pyo$']

Note the event name as it appears in the snippet, vimenter.

Filtering is the part with real consequences. The configuration sets an ignore pattern for compiled Python bytecode, and the prose describes filtering out .pyc, .git, .hg and .svn entries as well, so version control metadata and Python build residue stay out of the tree. Inside the tree window, question mark opens the operation guide.

The tree is also the place where the setup feels most opinionated, because the two autocommands assume a single-window editing style. Someone who wants the tree permanently docked beside the code will find these hooks working against that habit, and there is no switch described for turning the automatic open off other than editing the vimrc directly.

Ale checks on save and hands JavaScript to eslint

Syntax checking is handled by the Ale plugin, which is described as supporting C, C++, Go, Python, Haskell, Ruby, JavaScript and others. The mechanism is on save: when you write a file, Ale runs the checker and displays any errors it finds. JavaScript is the exception worth noting, because the checker there is eslint, chosen so that ES6 and JSX syntax can be checked as well. The README points to a separate blog post comparing JSLint, JSHint and ESLint with their Vim configurations, and say that switching the checker requires only a small configuration change.

The Python side rests on the pip-installed linters pep8, flake8, pyflakes and isort that the install steps pull in. Those are the tools the on-save behaviour leans on for Python files.

There is a gap here for anyone setting this up fresh. The dependency lists install the Python linters but never give a matching install step for eslint, even though eslint is the stated JavaScript checker. A reader who follows the dependency list exactly will find the JavaScript side looking for a tool that was never installed. The repository does include a file named eslintrc at the top level, so configuration for eslint is present, but the runtime dependency is not spelled out.

The Dockerfile compiles Vim from source on Debian bookworm

Alongside the plain install path there is a container, and the Dockerfile is the more interesting artifact of the two. It is a two stage build. The builder stage starts from debian:bookworm-slim and installs the build prerequisites: ca-certificates, exuberant-ctags, gcc, git, libncurses-dev, make, python3, python3-dev, python3-pip and wget. It then clones the upstream Vim repository and configures the build with the GUI and netbeans interfaces disabled, python3 interpreter support enabled, multibyte support on and the huge feature set selected, before compiling and installing it into the image.

The builder also fetches the vimrc into the root home directory and starts Vim once to let Vundle fetch the plugins, which is why the image ships a populated plugin directory. The final stage copies the installed binaries, the Vim runtime share directory, the vimrc and the .vim directory into a clean bookworm image, then adds the Python linters with pip using the break-system-packages flag. The container entrypoint is Vim itself, with help as the default command.

Three lines from the file show the shape of it:

FROM debian:bookworm-slim AS builder
WORKDIR /src
ENTRYPOINT [ "vim" ]

The images are published under two names, one on Docker Hub and one on the GitHub Container Registry, and the README offers the same run command for each.

Two ways to try it, and the volume mount that makes it usable

The trial path is Docker, and the reason for that is visible in the run command: the working directory is mounted at /src, which is the WORKDIR of the image. That means files in the current directory are visible inside the container and can be edited with the container's own Vim, including its plugins.

sudo docker run -it -v $PWD:/src --rm taobeier/vim
sudo docker run -it -v $PWD:/src --rm ghcr.io/tao12345666333/vim

Running the image interactively and mounting the current directory is what makes the container worth the disk space. A plain invocation of the image starts Vim and immediately prints help, which is not what anyone wants from a text editor. The two registry variants behave identically, and both are pinned to the same tag, so the choice between them is only about where the image is hosted.

For a local install instead of a container, the sequence is short: copy the vimrc to the home directory, open Vim once and let it install the plugins, or start Vim in ex mode pointing at that vimrc so the plugin bootstrap happens without waiting for a manual trigger. The local path gives you the same configuration, but it also installs plugins into your own home directory, and it expects curl for plugin search and a working ctags build on macOS.

MIT licensed, with release tags that trail the last push

The licence is MIT, which for a dotfiles repository matters mostly because it lets a reader take the vimrc, change it and use it without asking. The description of the repository is personal in tone, and the plugin list reflects one person's habits and language mix rather than a general purpose setup.

On maintenance, the numbers are uneven. The last push was on 2026-08-07, which is recent enough that the configuration is not abandoned. The release tags, however, tell a different story: the newest is v25.04.0 from 2025-04-18, and the two before it are v18.09.0 from 2018-08-31 and v18.08.0 from 2018-08-04. A gap of roughly a year between the newest tag and the last push suggests the tags are not used for every meaningful change, so a reader pinning to a release tag gets a configuration that is not the one on the master branch.

The repository is not archived. It holds a README and a Chinese README-zh.md, a Dockerfile, an install.sh, an eslintrc, a vimrc and a screenshot, and it publishes a homepage at moelove.info. A build badge points at a GitHub Actions workflow for the Docker image, so the container is produced automatically rather than by hand.

What the setup does not document, and how it compares to writing your own

Several gaps are worth knowing before you adopt this. The README never documents a rollback procedure, so there is no stated way to undo a plugin change if one breaks your editor. The plugin list is presented as one part of the configuration, which means the visible fragment may not be the full inventory you will inherit. The Python linters are installed by the documented steps while eslint is not, as noted earlier. The README also do not say which Vim versions are supported beyond requiring Python support, nor how to keep the container image in step with the master branch.

The obvious alternative is to write a vimrc yourself and add only the plugins you actually use. The trade-off runs in both directions. A self-written vimrc starts instantly, downloads nothing behind your back, and has no plugin set to audit. In exchange you assemble the same pieces by hand: a file tree, a fuzzy finder, a linter bridge and a plugin manager, and you maintain their update path yourself. This configuration inverts that, offering a coherent set in one file, at the cost of an install step that reaches the network, a plugin inventory you only partly see, and a first launch that takes as long as the clone step.

A second alternative is to take the container image as the environment and never touch a local Vim. That path removes the host dependency problems, including the Python build and the ctags compile on macOS, but ties your editing to an image that clones upstream Vim master at build time rather than a fixed version.

Editorial conclusion

Adopt this configuration if you want a ready-made Vim setup for Python and JavaScript and are comfortable inheriting someone else's key mappings and a plugin list you cannot fully see. Do not adopt it if you need a documented upgrade path, a pinned plugin set or a configuration your team can review end to end. Before committing, check that your Vim binary really has Python support, confirm the plugin set in the vimrc matches what your languages require, and see how the release tags track the last push, which was on 2026-08-07.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tao12345666333/vim on GitHub