ddc.vim is a completion framework that ships no sources, no filters and no UI

The framework is the empty space between your sources and your UI

ddc.vim is described as a dark deno-powered completion framework, and Ddc is the abbreviation of dark deno-powered completion. It provides an extensible and asynchronous completion framework for Vim and Neovim.

The most important thing in the documentation is the note at the very top. If you do not want to configure plugins, you do not have to use the plugin. It does not work with zero configuration. You can use other plugins.

And then the second note, which spells out what the package does not contain. Ddc.vim does not include any UIs, sources and filters. You must install them which you want manually, and you can search ddc plugins, sources and filters from a topic page on GitHub.

That is a design position, not an omission. A completion system has at least three separable parts: where candidate words come from, which of them are shown, and how they are drawn. A framework that ships the plumbing and leaves the three parts to plugins is a different product from one that ships a working default.

The payoff is that the parts are replaceable individually. The cost is that an empty ddc.vim gives you nothing, and assembling a working setup means choosing a source, a filter and a UI before anything appears in the popup. The screenshots in the documentation show a Neovim LSP completion and a command line completion, both of which are the result of that assembly rather than of the framework alone.

denops.vim was chosen over the Neovim Python interface

The choice of host framework is stated directly: the author chose the denops.vim framework to create the new plugin, because denops.vim is better than the Neovim Python interface.

The reasons given are a list of properties, and each one is a design constraint rather than a slogan. Easy to setup. Minimal dependency. Stability. Vim and Neovim compatibility. Speed. Library. Easy to hack.

The Vim and Neovim compatibility point is the one that matters most for a completion plugin, because completion is one of the most performance-sensitive things an editor does. The Neovim Python interface would have tied the plugin to Neovim only, and would have put a Python runtime in the critical path of every keystroke. Going through denops.vim, which drives an external process, keeps the same code working in both editors and keeps the slow part out of the editor's process.

The deno in the name is the other half of that decision. Deno is a separate TypeScript runtime, so the completion sources and filters are written in TypeScript and run outside the editor, communicating over the denops.vim bridge. The repository layout reflects it: there is a denops/ directory holding the TypeScript, a deno.jsonc for the Deno configuration, and an autoload/ directory for the Vim side.

The primary language of the repository is listed as TypeScript, which is the majority of what you would write if you wanted to add a source.

The version requirements are specific and the plugins are separate

The requirements section is short and the version numbers are precise, which is unusual for a plugin and reflects the plugin's dependencies on other projects.

The note at the head of the install section says it requires Vim 9.1.0448 or newer, or Neovim 0.10.0 or newer, and points at the requirements section for anyone unsure. The patch-level pin on Vim, 0448, is the sort of detail that matters when the plugin depends on specific features of the editor rather than only on its scripting interface.

Beyond the editor, you need Deno 2.3.0 or newer and denops.vim v8.0 or newer, with links to deno.land and the denops.vim repository.

The three requirements together form a stack, and each layer has to be current for the next to work. A denops.vim v8.0 requirement is a recent major version of the bridge, and a Deno 2.3.0 floor means a fairly new runtime.

The documentation itself lives in the repository as a Vim help file at doc/ddc.txt, and the README asks you to read it for details, with a help badge pointing at it. Two Japanese articles are linked for ddc.vim and for ddc.vim together with pum.vim, and the README notes you can read them by translation service, which is a nod to the fact that the primary documentation language is Japanese.

The development is supported through GitHub sponsors, which is noted in the README as the funding model.

The Makefile shows the whole toolchain is Deno

The build file is short and reveals that everything, including the tests, runs through Deno's own tooling rather than through Node or a separate test runner.

lint:
	deno check ${TS}
	deno fmt --check denops
	deno test --no-run -A ${TS}
	deno lint denops

test:
	deno test -A ${TSTEST}

format:
	deno fmt denops README.md .github

The two variables at the top explain the two targets. `TS` is every TypeScript file found under the denops directory, found with a shell find. `TSTEST` is the subset of those files that contain `Deno.test`, found with a recursive grep. The lint target type-checks and lints everything, and separately compiles the tests without running them, which is the check that catches a test file that does not type-check even when it is not the file you were editing. The test target runs only the files that actually contain tests.

The format target is interesting because it includes README.md and .github alongside the denops directory, which means the prose and the workflow files are formatted by the same tool as the source. That is a small thing that keeps a repository tidy without anyone having to remember it.

The repository layout is consistent with the architecture. The autoload/ directory holds the Vim side, the denops/ directory holds the TypeScript that runs under Deno, doc/ holds the help file, and deno.jsonc holds the Deno configuration. The .github/ directory holds the workflows.

The last push was on 2026-10-17, the repository is not archived, and there are no GitHub releases, so the plugin is distributed as a git checkout rather than as a tagged artefact.

Where this sits against the built-in completion and the other completion plugins

The comparison worth making is with what Vim and Neovim already give you, because that is the baseline ddc.vim has to beat.

Vim's built-in completion is keyword-based, works everywhere and needs no runtime. Neovim's built-in LSP completion is considerably better and is what most people mean when they say completion today. A framework that ships no sources and no UI is therefore not competing with either of those on capability; it is competing on control.

The case for a framework is that completion is a pipeline. Something produces candidates, something filters and ranks them, something draws them and decides what happens when you accept one. Editor-native completion tends to hardwire that pipeline, and a framework makes each stage replaceable. The cost is the assembly step that the documentation is upfront about.

The second comparison is with the other asynchronous completion plugins for Vim and Neovim, of which there are several, some of them built on the same denops.vim bridge and some not. The differentiator that the documentation names is the library framing. ddc.vim is meant to be a library other things are built on, and easy to hack, which is a statement about its intended role in a configuration rather than about its feature list.

The honest caveat is that the value of a framework is only realised once you have several sources or a UI you care about. A single language, one source and the built-in popup is a case where the framework adds setup without adding much.

The author's own framing is worth taking at face value. If you do not want to configure plugins, you do not have to use the plugin. That is a deliberate offer, and an unusual one to find in a plugin README.

Editorial conclusion

Adopt ddc.vim if you want an asynchronous completion setup you can shape piece by piece, and you are willing to install a Deno runtime, the denops.vim bridge and a separate source, filter and UI plugin for each capability you want. Skip it if you want a completion setup that works after one install, because the documentation says explicitly that ddc.vim does not work with zero configuration and includes no sources, filters or UIs. Verify first that your Vim is 9.1.0448 or newer or your Neovim is 0.10.0 or newer, that Deno 2.3.0 or newer and denops.vim v8.0 or newer are present, and that the ddc-vim topic on GitHub has a source and a UI for the languages you actually edit.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Shougo/ddc.vim on GitHub