vim-dogrun: a dark colorscheme whose palette comes out of a Rust generator

A colorscheme whose colour definitions are Rust source

vim-dogrun is described as a dark colorscheme for Neovim and Vim, aimed at both the GUI and terminals that offer 256 colours or true colour. The unusual part is where the colours come from. The project states that loading is fast because the colorscheme files are precompiled, and that the colour definitions are maintainable and consistent because they are powered by a Rust based generator.

The repository layout backs that up. There is a generator directory holding the generator itself, a colors directory for the shipped scheme, an autoload directory, a term directory, and a wezterm directory that holds the terminal side of the palette. The primary language of the repository is listed as Rust, which is unusual for a colorscheme and explains why the palette is treated as a build artefact rather than as a hand edited file.

The installation pitch is that no configuration is required to start using it. That claim is narrow and accurate: there is nothing to configure in the theme itself, because a colorscheme is loaded by name and the file already exists. It does not mean the theme adapts itself to your setup. A theme has no idea which plugins you run, so the plugin support listed in the documentation is a static mapping that can lag behind what you actually use.

The licence is MIT, and the project lists maintainer wadackel as the copyright holder.

Installing through vim-plug or lazy.nvim takes one declaration

Two plugin managers are documented, and the difference between them matters for a colorscheme. With vim-plug, the declaration is a single line:

Plug 'wadackel/vim-dogrun'

With lazy.nvim, the spec is a table, and it shows two settings that say something about the design:

{
  'wadackel/vim-dogrun',
  lazy = false,
  priority = 1000,
}

The lazy = false setting means the plugin is not deferred, so the colorscheme is available as soon as the plugin manager starts, which is what a theme needs. The priority of 1000 makes it load before other plugins, so that plugins which read colour groups at startup see the theme already applied.

If you use neither manager, the repository is a normal Vim plugin directory, and the autoload and colors folders are the standard layout a runtimepath load expects.

One detail from the surrounding notes is worth keeping in mind. The project says there may be separate themes in future, but for now the approach is inline themes for each tool, meaning the WezTerm and fzf colours are part of this one project rather than a set of independent ports you might find elsewhere.

Applying the scheme and the two statusline integrations

Activation is one line in your $MYVIMRC, which the documentation names as .vimrc or init.vim:

colorscheme dogrun

That is the entire runtime configuration. There are no options block, no toggle variables and no setup function, so the theme is also a poor choice for a user who expects to tune contrast or hue per project.

Two plugins get a dedicated integration, and in both cases the wiring is a variable rather than a function call. For lightline.vim you point it at the theme by name:

let g:lightline = {
  \ 'colorscheme': 'dogrun',
  \ }

For vim-clap the setting is a plain string:

let g:clap_theme = 'dogrun'

That is the whole extension surface for statuslines. Other statusline plugins are not covered by a documented setting, so if you use something else, its colours come from whatever that plugin derives from the active highlight groups, and you may see a mismatch against the terminal palette. The plugin list in the documentation names lightline.vim and vim-clap among many others, but most of those entries simply mean the colours look correct when that plugin renders, not that the plugin has a dedicated theme hook.

Filetypes, language servers and the plugin compatibility list

The scheme supports Neovim's built in language server client and LSP semantic highlights, and it works with nvim-treesitter. The documented filetype coverage is a specific list rather than a claim of everything: c, cpp, cs, diff, go, graphql, html, javascript, json, make, markdown, python, ruby, rust, toml, typescript, vim, yaml and zsh. Several of those names are paired with a plugin in parentheses, such as go with vim-go, graphql with vim-graphql, markdown with vim-markdown, rust with rust.vim, toml with vim-toml and typescript with yats.vim, which tells you which parser the colours were checked against.

The plugin list is longer and includes ALE, Copilot.vim, coc.nvim, nvim-cmp, Blink Completion, Diffview.nvim, gitsigns.nvim, telescope.nvim, fzf.vim, nvim-tree, fidget.nvim, nvim-notify, flash.nvim, mini.jump, hop.nvim, eda.nvim, avante.nvim, fugitive.vim, fern.vim and others. One entry carries a qualification: snacks.nvim is listed with partial support.

This list is the most useful part of the documentation for anyone deciding, and it is also the part most likely to age badly. The list is a snapshot of what was checked, not a mechanism that verifies anything, so a plugin that has since changed its highlight groups can render with the wrong colours while the documentation still claims support.

The same palette reaches WezTerm and fzf through separate files

The editor is only part of the project. WezTerm support ships a toml file named wezterm/dogrun.toml, and the installation is a copy into the terminal's colour directory:

cp wezterm/dogrun.toml ~/.config/wezterm/colors/dogrun.toml

Then the terminal configuration selects it by name:

return {
  color_scheme = "dogrun",
}

For fzf, the approach is a shell export rather than a config file, and the exact colours are visible in it. The foreground is #8085a6, the background #222433, the highlight #bdc3e6, the selected background #363e7f, with the info colour #929be5, the pointer and marker #b871b8, the spinner #73c1a9, and the prompt, header, border and gutter set to #32364c or -1:

export FZF_DEFAULT_OPTS='--color=fg:#8085a6,bg:#222433,hl:#bdc3e6,fg+:#8085a6,bg+:#363e7f,hl+:#bdc3e6,info:#929be5 --color=prompt:#32364c,pointer:#b871b8,marker:#b871b8,spinner:#73c1a9,header:#32364c,border:#32364c,gutter:-1'

The export belongs in ~/.zshrc or ~/.bashrc. This is a real advantage over picking a colorscheme and picking a terminal theme separately, since the values match by construction. It is also manual work, since the fzf colours are a shell string you maintain rather than something the plugin loads.

A hand written scheme and a generated scheme fail differently

The natural comparison is with a conventional hand maintained Vim colorscheme, and the project names its own inspiration in that category with vim-color-spring-night. The difference in approach is not about how the colours look but about what happens when you want to change one.

In a hand written scheme, the palette is a file of highlight definitions in the colours directory that you can open, edit and reload. The cost of a change is one file and a reload. The benefit is that the file is readable by anyone who knows Vim script, and that you can fork it and own it completely.

In vim-dogrun, the colour definitions are source for a Rust generator, and the shipped colours directory holds the precompiled output. The benefit the project claims is consistency, since one definition drives every file type and every tool, and the same generator produces the terminal and fzf values. The cost is that the source of truth is a Rust program, so a fork means reading the generator, and building it needs a Rust toolchain.

For most users the difference is invisible until the day they want to change something. If that day arrives, a theme you can edit in place is easier to fork, while a generated theme is easier to keep internally consistent. The Rust toolchain requirement is also the one thing that stops this project from being a pure drop in for people who only want a colours directory.

The limits of a single dark scheme

The constraints are clear from the description rather than hidden. The scheme is dark, and there is no light variant, and the project says separate themes may come later but that for now the plan is inline themes for each tool. If you work in bright rooms, or you need a light scheme for daytime, this project does not cover you.

The filetype list is nineteen entries long. That is generous for a scheme, but it is not coverage, and a language you write that is not on the list will fall back to whatever the editor defaults provide, which in a dark scheme usually reads as a visual hole.

On maintenance, the facts are modest. The repository is not archived, the last push was on 2026-09-26, and there are no GitHub releases at all, so there is no tagged version to pin or to roll back to. A CI workflow is referenced from the project page and renovate.json5 sits at the root for dependency updates, and an AGENTS.md file is present, so the project has the usual scaffolding. With no release series, the practical approach is to track the main branch and treat the theme as a moving target, which is a low risk for a colourscheme and an argument against nothing more than reproducibility.

The MIT licence means nothing here constrains your fork, in either the editor or the terminal.

Editorial conclusion

Adopt vim-dogrun if you use Neovim or Vim in a dark setup, want a single palette shared by the editor, WezTerm and fzf, and are willing to keep a Rust toolchain in the loop when the colour scheme is regenerated. Do not adopt it if you need a light theme, a broader set of filetypes, or a plugin statusline beyond the lightline and vim-clap integration that is documented. Verify first that the plugin list on the project page covers the plugins you actually run, since snacks.nvim is marked as partial support and the release history contains no GitHub releases, with the last push on 2026-09-26.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wadackel/vim-dogrun on GitHub