vim-doge turns a blank docblock into a checklist you can tab through

It writes the structure and leaves the words to you

The README opens with a Martin Fowler quotation about code that humans can understand, and then states the problem plainly: everyone likes documentation because it makes codebases easier to understand, yet no one has time to write it in a good and proper way.

vim-doge is a documentation generator that produces a proper documentation skeleton based on certain expressions, mainly functions. The described workflow is the whole product. You put the cursor on a function, press <Leader>d, jump quickly through the TODO items using <Tab> and <S-Tab> to quickly add descriptions, and go on coding.

The design decision is that the hard part is the structure, not the words. Knowing that a Python function needs a summary line, a parameter per argument with a type, a returns section and a raises section is mechanical once you know the standard, and getting it right by hand on every function is the part that takes time and gets skipped. The plugin knows the standard, so it emits the empty version with the fields marked, and the only thing left for the author is the sentence in each field.

The TODO markers are the mechanism that makes that work, because a tab that jumps to the next empty field turns a documentation chore into a sequence of small prompts. A plugin that only inserted a template would save you thirty seconds per function. A plugin that also moves you through the fields saves you the mental accounting of where you are.

The audience is a Vim or Neovim user who documents as they code, in a codebase with enough of a convention that the structure is worth enforcing.

Nearly twenty languages, and the list is a coverage map

The supported languages and doc standards table is the substance of the project, and it is worth reading as a map of what the plugin can parse.

Python has the widest coverage, with reST, Numpy, Google, Sphinx and Doxygen styles. C has Doxygen and KernelDoc. C++ has Doxygen, Java and Groovy have JavaDoc, C# has XMLDoc, Bash has the Google style, and R has Roxygen2. Lua has LDoc, Ruby has YARD, Scala has ScalaDoc, Rust has RustDoc, PHP has phpdoc.

JavaScript and TypeScript share JSDoc, and the JavaScript row is spelled out in detail: Vanilla, ES6, FlowJS, NodeJS, Svelte and Vue. HTML is supported, and the table is explicit about the mechanism, through inline script tags, which is a narrow and honest limitation rather than a vague claim.

The principle behind the list is stated at the top: every language that has a documentation standard should be supported, and the README asks for suggestions of new languages and new doc standards.

Two things follow from the design. The first is that the plugin is filetype driven rather than language server driven, so it works for a language your editor has no LSP for, and the ftplugin/ directory at the top of the repository is where those per language rules live. The second is that the plugin knows the shape of a docblock but nothing about your code, so it can produce the parameters section and the type annotations of the standard, but it cannot know what the function actually does.

The keypress loop is the feature

It is worth being precise about the interaction, because the name of the plugin and the feature list understate it.

You place the cursor on a function, press <Leader>d, and the plugin inserts the skeleton for that function in the standard configured for that filetype. The inserted skeleton contains TODO items in each field that needs prose. Then <Tab> moves to the next TODO and <S-Tab> moves back, and you type the descriptions.

The subtlety is that the plugin is not limited to a single function in a single place. The configuration options listed in the README include g:doge_buffer_mappings, which points at a set of buffer local mappings, and g:doge_mapping_comment_jump_forward and g:doge_mapping_comment_jump_backward, which are the comment jump mappings. Together with g:doge_comment_interactive, g:doge_comment_jump_wrap and g:doge_comment_jump_modes, they describe a mode where the jump behaves interactively, wraps around, and can be switched between modes.

The result is that the plugin can be used to sweep a whole file. You generate the skeleton for one function, fill the TODOs, and move to the next, which converts documentation from a separate pass into something that happens at the point of writing the function. That is the difference between a template engine and a workflow tool, and it is why the option list is longer than a simple insert would need.

The README also links a demo page, which is the fastest way to see the flow without installing anything.

Installation builds a Rust helper

The plugin manager route is a single line in a Vim plugin configuration file, Plug 'kkoomen/vim-doge', { 'do': { -> doge#install() } }, and the do block is the interesting part, because the install step builds something.

The vim-pack route is explicit about it:

git clone --recursive --depth 1 https://github.com/kkoomen/vim-doge ~/.vim/pack/*/start/vim-doge

and then, with the plugin on the path, you open Vim and run:

:call doge#install()

The repository layout explains what that call does. There is a helper/ directory at the top level, and the project's primary language is Rust, so the helper is a native binary built during installation. The clone is done with --recursive and --depth 1 because the helper sources are needed, and the install function compiles them.

That is the main operational constraint of the plugin, and it is not a Vimscript only tool. The README's development section names the helper as a distinct piece of the workflow, alongside environment setup and testing locally, and the contributing section has a Tree sitter subsection, which points to how the language definitions are maintained.

The version badges are the other practical detail. The minimum supported Vim version is 7.4.2119, and the minimum supported NeoVim version is 0.3.2, so the plugin is not restricted to a recent editor, but the install procedure is a build step rather than a file copy, and a machine without a Rust toolchain or without network access to fetch the helper sources will not complete it.

Configuration is a list of global variables

The options are all global variables prefixed with g:doge_, and the README's table of contents lists them individually, which makes the configuration surface easy to audit.

g:doge_install_path is where the helper lives, which matters for anyone with a non standard installation or a restricted environment. g:doge_enable_mappings is the switch for the whole mapping set, and g:doge_mapping is the mapping itself, so a team that wants a different key than <Leader>d can have one. g:doge_filetype_aliases is the mechanism for mapping filetypes onto each other, which is how a language with several doc standards is disambiguated.

Then the comment jumping options: g:doge_buffer_mappings, g:doge_mapping_comment_jump_forward, g:doge_mapping_comment_jump_backward, g:doge_comment_interactive, g:doge_comment_jump_wrap and g:doge_comment_jump_modes.

The command :DogeGenerate {doc_standard} is the explicit form, where the doc standard is given as an argument. That is what the language specific configuration sections are about, with separate sections for JavaScript, PHP, Python and Doxygen, since those are the cases where the default for the filetype is not the one you want, and where the command lets you pick the standard per invocation.

There is also a headless mode and a help section, both of which matter for a plugin that a team may want to run in a script or a CI job rather than interactively, though the README does not detail the headless interface beyond naming it.

The overall shape is a plugin with a meaningful configuration surface rather than a single toggle, and the fact that every option is a documented global variable means a team can put its conventions in a shared configuration file and check it into the repository.

Tree sitter, the test suite and the plugin packaging conventions

The contributing section of the README has a Tree sitter subsection, and that tells you how the language support is extended. Rather than pattern matching on function signatures with regular expressions, the project uses Tree sitter parsers, which give a real syntax tree for a language. That is a heavier dependency than a plugin strictly needs and it buys accuracy, particularly for languages where the definition of a function is not a simple keyword and a brace.

The repository supports this with a test/ directory, a doc/ directory for the Vim help file, an addon-info.json file, and a .vintrc.yaml, which is the configuration for vint, the linter used for Vimscript plugins. The .version file, the CHANGELOG.md, the CONTRIBUTING.md, the CODE_OF_CONDUCT.md and a CLAUDE.md complete the picture of a project with its conventions written down.

The addon-info.json file matters more than it looks, because it is the metadata format used by the Vim package manager directories, so the plugin can be discovered and installed as a package rather than only as a git clone.

The result is a plugin that is careful about the parts that are usually skipped. The trade is that the dependency footprint is larger than a pure Vimscript implementation would be, since there is a Rust helper to build and Tree sitter grammars to fetch, and the trade is justified by the accuracy of the generated skeletons.

The alternative worth naming is the one your editor may already have. Most language servers can generate a doc comment for the symbol under the cursor, and an IDE can usually insert a template. The difference in approach is that those are per language and tied to a running LSP, while vim-doge is filetype driven, works across languages without a language server, and follows a documentation standard rather than a language's own conventions. The price is that it knows nothing about the code, only about the standard, so the type annotations and parameter list it writes are the standard's, not derived from a type checker.

Maintenance, licence and the boundary of the tool

The licence is GPL-3.0, and the repository is not archived with the last push on 2026-08-13.

The release history has a gap worth noticing. The tags are v4.7.1 from 2026-08-12, v4.7.0 from 2024-05-01 and v4.6.3 from 2024-03-09. So the project has been moving in fits and starts, with a long gap between the 4.7.0 release and the 4.7.1 patch, and the most recent work concentrated in a single release more than two years after the previous one. The repository is not dead and the last push is recent, but the version line does not suggest a busy release cadence, and a team depending on it should plan around that rather than assume regular tags.

The boundary of the tool is worth stating in one sentence, because it is the thing people ask. vim-doge generates documentation skeletons. It does not write documentation, it does not summarise the function, and it does not check that the prose you type matches the code. A team that expects a documentation generator to produce accurate descriptions will be disappointed, and a team that wants consistent structure in every docblock will not.

The other boundaries are smaller and visible in the table. HTML is only covered through inline script tags, so a project with script blocks in external files or with a document oriented template is partly out of scope. The language specific configuration sections exist because the default standard per filetype is sometimes wrong, which is a sign of a mature mapping rather than a rough one.

For a team, the sensible evaluation is to install it, generate a skeleton for a handful of functions in the languages you actually write, and check whether the output matches your house style closely enough that you would not edit it. If the answer is yes, the plugin removes a real chore. If the answer is no, and the reason is that your conventions differ from the supported standards, then the fix is a fork of the filetype rules, which is a small change, or a different tool entirely.

Editorial conclusion

vim-doge suits a Vim user who writes documentation as part of the function and has a team convention for docblock structure, and who wants the structure generated rather than typed. It does not suit someone who wants prose written, since the plugin produces an empty skeleton with TODO markers, and it is the wrong tool if your language already has a language server that generates doc comments with real signatures. Verify first that your filetype is on the supported list, since HTML is only covered through inline script tags, and note that the helper binary is built from Rust source during installation, so a machine without a working toolchain or network access to fetch the helper will not complete the install.

Frequently asked questions

Official sources

1. Issues
2. kkoomen/vim-doge on GitHub
3. License: GPL-3.0
4. README
5. Releases