Vimade: dimming inactive windows without throwing away syntax colors

Fading that keeps the syntax highlighting alive

Vimade exists to help you maintain focus on what matters. It dims, fades and tints inactive windows and buffers, and it can also provide limelight style or twilight style highlighting around the cursor. The part that separates it from the usual approach is stated in the README: Vimade preserves syntax highlighting, so you stay in context while the window you are not working in recedes. That matters in practice. A plugin that blanks or flattens the colours of inactive windows removes the information that tells you what file you will return to, and what kind of code it holds. Vimade instead recomputes the colours of the inactive content so that the syntax still reads, only quieter. The feature list in the README also mentions pre-built recipes, smooth animations, compatibility with all colorschemes and even other plugin namespaces, and a sub-millisecond performance claim. Whether that performance figure holds on your machine is something only you can judge, but the design intent is clear from the option names.

setup is an overlay, not a merge

The configuration guide contains the warning that catches most new users. Vimade treats the setup call as an overlay, and each time you call it, it overrides any previous settings. So if you want to combine options, they all have to be in the same call, and to reset to the defaults you call setup with an empty table. The README shows the correct shape, with the recipe and the fade level together:

require('vimade').setup({
  recipe = {'minimalist', {animate = true}},
  fadelevel = 0.3,
})

And the incorrect shape, where a second call silently replaces the recipe chosen in the first. The same overlay rule applies in the other configuration languages, since the vimscript form sets variables under g:vimade and the Python form calls vimade.setup. It is a small thing to get wrong, but the symptom is a setting that appears to be ignored, which is a confusing way to discover the behaviour.

ncmode decides what counts as inactive

The ncmode option controls how Vimade decides which windows to fade, and the three values cover genuinely different intentions. The buffers mode is the default, and it fades all windows that do not share the same buffer as the active window, which is useful when the same buffer is open in several splits and you want all of them to stay highlighted. The windows mode fades all inactive windows, giving a clear distinction between the window you are working in and everything else. The focus mode only fades when the VimadeFocus command is active, and it is marked as requiring Neovim 0.10 or newer, which makes it the on-demand option. The README suggests trying each one, and the difference between the first two is the one worth thinking about: with buffers, a file open in two splits lights up in both, with windows, only the focused split lights up. The setting is available in all three configuration languages:

require('vimade').setup{ncmode = 'buffers'} -- or 'windows' or 'focus'

The vimscript equivalent sets g:vimade.ncmode, and the Python equivalent passes ncmode to vimade.setup.

basebg exists because transparent terminals break the maths

Fading a colour means computing a new colour relative to a reference, and the reference has to be known. With a transparent terminal your Normal highlight group has a background of NONE, which means Vimade cannot see the real background colour behind the text and will compute the faded colours against the wrong base. The guide gives a procedure rather than a guess. Place the transparent terminal over a pure white background, use a colour picker to find the background colour of the terminal, and set the basebg option to that value, darkening it slightly if needed for the best result. The option accepts a hex string or a list of three numbers:

require('vimade').setup{basebg = '#2d2d2d'} -- or {45, 45, 45}

This is a real limitation of the approach rather than a bug. Any plugin that recolours highlights has to know what it is recolouring against, and a terminal that reports no background removes the information. It also means the same configuration can look right on one machine and washed out on another, which is worth knowing before you tune the fade level.

tmux is where fading usually falls apart

The troubleshooting section for tmux is the most useful part of the documentation for anyone running Vimade in a terminal multiplexer, and the fixes are specific. First, Vimade requires a 256 colour terminal, and by default tmux may set t_Co to 8, so it is recommended to export TERM=xterm-256color before starting Vim. If the terminal supports it, setting termguicolors inside Vim gives a more accurate level of fading. Second, for windows to fade when you switch between tmux panes, focus events have to be enabled on three fronts. In Vimade you turn on enablefocusfading, in the tmux configuration you add set -g focus-events on, and Vim users may also need the tmux-plugins/vim-tmux-focus-events plugin. The tmux behaviour is not Vimade's own, it is the multiplexer deciding whether to report focus changes at all, which is why the fix spans two configuration files and sometimes a third.

Three installation paths and two implementation languages

The plugin can be installed with lazy.nvim, where the options are given in the plugin specification itself:

{
  "tadaa/vimade",
  opts = {
    recipe = {"default", {animate = true}},
    fadelevel = 0.4,
  }
}

Or with vim-plug, which needs only the plugin line:

Plug 'TaDaa/vimade'

After installation the plugin can also be configured directly, in Lua for Neovim only, in vimscript, or in Python. The version rules are the part to read carefully. Neovim 0.8 and newer use a pure Lua implementation, while for Vim and for older versions of Neovim, Python is required, and the Python configuration is wrapped in a Vim function that is triggered by the Vimade#PythonReady user event, so the setup call happens lazily once Python becomes available. Some features, focus mode among them, require Neovim 0.10 or newer. So the plugin is not one codebase but two, and the feature set you can rely on depends on which editor and which version you run.

Repository layout, licence and the release trail

The repository is a classic Vim plugin layout with the usual directories, autoload/ for the lazily loaded functions, plugin/ for the file that runs at startup, lua/ for the Lua implementation, lib/ for the Python side, and doc/ for the help files, alongside a vimade.vimdoc.vim file and a colors.sh script at the root. The licence is Apache-2.0, with the text in the LICENSE file. The release history is tagged and named, with v2.5.1 named Shiva Blizzard from 2025-12-14, v2.5.0 named Shiva from 2025-04-06 and v2.1.2 named shiva from 2024-12-28. The default branch is master, and the last push was on 2026-09-29. That gap between the last tagged release and the last commit is worth noting for anyone pinning versions, since the changelog in the repository rather than the tag list is where the recent work appears.

Editorial conclusion

Vimade suits people who split their editor into many windows and want the active one obvious without giving up colour in the others, especially Neovim users on 0.10 or newer who can use the focus mode. It is a poor fit if your terminal reports a background of NONE and you are unwilling to set the basebg option, since the faded colours will be computed against the wrong reference, and it is unnecessary if a single window is all you use. Before configuring it, decide on one recipe and one ncmode, put them in a single setup call, and check whether your multiplexer reports 256 colours and focus events.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. TaDaa/vimade on GitHub