# vim-orgmode's makefile still runs the test suite on Python 2 > vim-orgmode is a Vim plugin that reimplements the outlining and task-management parts of an Emacs mode, with its own readme and changelog written in the file format it emulates. The feature list opens by admitting it is incomplete, the export path runs through Emacs, and the build file underneath still invokes a Python 2 interpreter for its tests and a retired continuous integration service for its builds. **jceb/vim-orgmode** — Text outlining and task management for Vim based on Emacs' Org-Mode - Repository: https://github.com/jceb/vim-orgmode - Website: http://www.vim.org/scripts/script.php?script_id=3642 - Stars: 3,186 · Forks: 268 - Language: Python - License: NOASSERTION - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/jceb-vim-orgmode ## The readme and the changelog are written in the format it emulates The repository's own documentation is in the format it exists to support. The readme at the root is an Org file, and so is the changelog. The usage guide, by contrast, is a plain text file in a documentation directory, which is the older convention for Vim plugin help. That is a small detail with a real consequence. A user of the plugin can read its documentation in the editor the plugin is for, which is a genuine advantage over a plugin whose documentation is only on a web page. And a contributor editing the changelog is editing the same syntax the plugin parses, so mistakes in the changelog are the kind of mistake the plugin itself would report. The readme also preserves its origins as raw link syntax rather than rendered anchors, so the text carries the full tracking-laden addresses of the badges, the chat room and the coverage service. Two of those services are the subject of a later section. The homepage recorded for the repository is not a site of the project's own but a script page on the Vim project's site, at a long-standing numeric identifier. That is the distribution channel of a classic Vim plugin, and it tells you the audience. ## The feature list opens by admitting it is incomplete The heading of the feature section is a bold marker followed by the word Features, and the first sentence under it is a disclaimer. It says the plugin does not support all of the Org mode's features but is quite usable, and that what follows is a short list of the features already supported. Then the list itself, which is nine items long. Syntax highlighting. Cycling the visibility of headings, which is folding. Navigating between headings. Editing the structure of the document, adding, moving, promoting and denoting headings. Hyperlinks inside the plugin and outside, to files and to web pages. To-do list management. Tags on headings. Lists in both alphanumeric and bullet notation, with checkbox support. Basic date handling. And exporting to other formats. So the scope is not ambiguous. It is an outlining and task plugin, not a reimplementation of everything, and the page says so before it lists anything. Two details in the prose are worth noting. The introduction credits the mode it imitates with folding, sparse tree views and task scheduling, and says these are completed rather than complemented by hyperlinks, tags, to-do states and priorities. And the spelling of that sentence trails off, which tells you the readme has been edited over years rather than rewritten. ## Export runs through Emacs, not through Vim The last item in the feature list is the one that qualifies the rest. Export to other formats is offered, and the parenthetical says how: via the Org mode of the text editor the plugin is imitating. So the conversion path leaves the editor entirely. For a user that is a defensible choice. Org's export system is mature, it covers a great many output formats, and reimplementing it in a Vim plugin would be wasted effort. The cost is that exporting needs a working installation of that other editor, which is a heavy dependency for a plugin whose entire premise is avoiding it. It also means the boundary of the project is drawn in a slightly surprising place. Everything about outlining, folding, navigation, tags, to-do state and dates is implemented here. Everything about leaving Org format is delegated. A user whose workflow is read and edit inside the file is fully served; a user whose workflow includes conversion needs two editors. The page does not discuss that dependency anywhere else, which is the main thing to know before choosing the plugin for a conversion-heavy pipeline. ## The default target builds nothing, and packaging drives a headless editor The build file is the most revealing document in the repository, and its first two targets are almost empty. The default target is the build target, and the build target has no recipe at all. So running the default target does nothing, which is correct for a plugin that ships as scripts rather than as a compiled artefact, but surprising to anyone expecting a build. Packaging is where the file does its work. There is a target that produces a Vim ball archive, and it depends on three things: the check target, a packaging script, and a clean. It then installs the plugin into a temporary directory with a staging prefix, generates a file list with a substitution, copies the packaging script alongside, and then runs the editor itself in a silent batch mode with a command-line variable set to the plugin name, to produce the archive. If the archive comes out under the expected name it is moved; otherwise the target succeeds anyway. From that one artefact the file derives four more targets, two for the compressed form and two for the alternate extension, plus four alias targets with the extension omitted. The last line of that block gzips the compressed file. So there are eight targets serving two real files, which is the kind of compatibility surface a plugin accumulates over twenty years. ## Install copies five runtime directories, matched by file extension The install target lists its inputs explicitly: the documentation directory and four runtime directories, one each for filetype detection, filetype plugins, indentation and syntax. Those five are the conventional layout of a Vim plugin, and the install step works by walking them with a single find expression that selects files by extension. Four extensions are matched: plain text files, configuration files, Python files and Vim script files. Each match is then installed, with the directory structure recreated under a destination directory and a runtime path derived from a prefix that defaults to a system location under the local share directory. Two details make it scriptable rather than manual. The destination directory is a separate variable, so a packager can stage into a staging root without editing the file. And the file mode for installed files is fixed, while directories are created executable so the tree is traversable. The consequence for a contributor is that the install target is also the packaging target: the Vim ball recipe installs the plugin into a temporary tree using exactly this mechanism. One copy rule, used twice. ## Tests run on Python 2, coverage on nose2, lint with warnings off Three quality targets, and each one names a tool that dates the project. The test target depends on a check target, whose recipe changes into the tests directory and runs a script with a Python 2 interpreter. That is the unit suite for the plugin's Python parts, and the interpreter named in the file is one that current distributions no longer install by default. The coverage target echoes a reminder that it depends on two specific packages being installed, then runs a test runner in the nose style with coverage and an HTML report. So the coverage path still assumes the older nose lineage rather than the current default runner. The lint target does the same thing with an echo, then runs a Python linter with a configuration file from the repository root and a long list of disabled checks. The list is the interesting part: it turns off the line-length check, several naming and formatting checks, and then a bare entry that disables warnings wholesale. So the project has a linter configuration, a coverage report and a unit suite, and all three are wired to tooling generations behind what a current Python installation provides. Nothing about that is unusual for a long-lived project; it is simply the maintenance surface a new contributor inherits. ## Continuous integration points at a service the project no longer uses The badges tell the story in two lines. There is a chat badge, a build badge pointing at a continuous integration service that is no longer operating, and a coverage badge pointing at a hosted coverage service. The repository carries a configuration file for that same continuous integration service at its root. So the build pipeline described by the repository is one that will not run, while the coverage badge is the only signal in the header that might still be live. The other signal is the branch itself. There are no published releases at all, and the most recent commit is dated in March 2026. For a plugin distributed as scripts through the Vim project's script page, no releases is the normal shape, since installation does not come from a tagged archive. The commit date is the number worth watching. On licensing there is a similar gap. The repository's licence field is not asserted, a licence file is present at the root, and the readme points at that file for the terms rather than restating them. ## The clean target rebuilds the documentation it just deleted One small thing in the build file is worth reading twice, because it is the kind of detail that costs an afternoon. The clean target depends on the documentation target. Before it deletes anything, it makes the documentation. Then it removes compiled Python files and coverage data, removes the archive files and their compressed forms, and removes the two temporary directories the packaging recipe created. Then it changes into the directory it came from and runs make again with the same target. So cleaning is not a leaf operation: it reaches into the documentation directory, builds it, and re-enters it. For a target whose name promises removal, that ordering is unusual, and it means a clean in a fresh checkout may fail before it deletes anything if the documentation build has unmet dependencies. It is also the clearest single illustration of this repository's character. The feature list is honest about its limits, the build file is explicit about what each tool needs installed, and the code is from an era when a plugin of this size was maintained by one person on a personal machine. ## Conclusion vim-orgmode suits a Vim user who works in Org files and wants folding, to-do state and tags without switching editors. Three things to check before you commit to it. The feature list is explicitly a short list rather than a parity claim, so check the guide for the specific constructs you need. Exporting to other formats goes through Emacs, so budget for that if your workflow leaves Org. And read the build file before you run any of it, because the default target compiles nothing, the clean target builds documentation, and the test target needs a Python 2 interpreter that most current systems no longer ship. ## FAQ ### How can I use Org mode in Vim? This plugin is one way: it provides text outlining and task management for Vim based on the Emacs mode of the same name, covering syntax highlighting, heading folding and navigation, structural editing, hyperlinks, to-do list management, tags, lists with checkboxes and basic date handling. ### Is vim-orgmode still maintained? There are no published releases, and the most recent commit to the branch is dated 2026-03-09. The repository carries a continuous integration configuration for a service that no longer operates, and the licence field recorded against the repository is not asserted, though a licence file is present at the root. ### What does vim-orgmode not support? The page says outright that the plugin does not support all of the Org mode's features but is quite usable, and it gives the list of what it does support as a short list rather than a parity claim. Nine areas are named, from syntax highlighting through basic date handling. ### How do I export from vim-orgmode to another format? Through the Org mode of the text editor the plugin imitates. Everything about reading and editing an Org file is implemented in the plugin, while everything about leaving the format is delegated to that other editor. ### How is vim-orgmode tested? The build file has three quality targets. The test target delegates to a script in the tests directory and runs it under a Python 2 interpreter. The coverage target uses a test runner in the nose style with an HTML report and echoes a reminder that two packages must be installed first. The lint target runs a linter with a repository configuration and a long list of disabled checks, warnings among them. ### Where are the vim-orgmode documentation and changelog? The usage guide is a plain text file in the documentation directory, and the licence is a file at the repository root. The changelog and the readme are both written in the same Org syntax the plugin emulates, so a contributor edits the format the plugin parses. ## Sources - [Issues](https://github.com/jceb/vim-orgmode/issues) - [jceb/vim-orgmode on GitHub](https://github.com/jceb/vim-orgmode) - [Project website](http://www.vim.org/scripts/script.php?script_id=3642) - [README](https://github.com/jceb/vim-orgmode/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jceb-vim-orgmode