Vague for Neovim: a low contrast dark theme with a colour table you can edit

What the theme is, and what the description claims for it

Vague is described as a cool, dark, low contrast colour scheme for Neovim, and the tagline in the repository description is more evocative than technical, pastel yet vivid, like a fleeting memory. So the design brief is a dark theme that avoids the hard contrast of a highlighter on black, and the palette reflects that with a background of a near black grey and a foreground of a soft light grey. The primary language is Lua, which is the norm for Neovim themes, the licence is MIT with the file in the repository root, and the last push was on 2026-10-08 with the repository not archived. The topics are the usual set for this kind of project, colorscheme, neovim, neovim-colorscheme, neovim-plugin and neovim-theme, and the releases are v2.1.3 from June 2026, v2.1.4 from July and v2.1.5 from October, so the theme is being maintained.

The installation, which uses the Neovim package API

The Installation section is two lines, and the first one tells you which Neovim generation the theme expects. You add the repository with vim.pack.add, passing the GitHub URL, and then you set the colour scheme with vim.cmd.colorscheme, passing the name vague. The pack API is the mechanism recent Neovim versions provide for installing plugins and colour schemes, and using it means there is no plugin manager to configure and no lockfile to maintain. The alternative for people who still run a plugin manager, such as lazy.nvim or packer, is not documented in the README, so if that is your setup you are expected to work it out from the repository layout, which is colors/ for the colour definitions and lua/ for the Lua module. The theme name and the module name are the same, vague.

vim.pack.add({ 'https://github.com/vague-theme/vague.nvim' })
vim.cmd.colorscheme('vague')

The colour table, and why it is exposed as names

The Configuration section is the heart of the README, and the design choice in it is that the palette is a set of named colours rather than a pile of highlight definitions. The default table lists a background of #141415, an inactive background of #1c1c24, a foreground of #cdcdcd, a float border of #878787, a line colour of #252530 and a comment colour of #606079. Then a semantic colour for each syntax class, with builtin at #b4d4cf, func at #c48282, string at #e8b589, number at #e0a363, property at #c3c3d5, constant at #aeaed1, parameter at #bb9dbd, operator at #90a0b5, keyword at #6e94b2 and type at #9bb4bc. Then the interface colours, visual at #333738, error at #d8647e, warning at #f3be7c, hint at #7e98e8, search at #405065, plus at #7fa563 and delta at #f3be7c. The point of naming them is that a user who wants a different string colour changes one line rather than rewriting a highlight group.

The three setup options that matter

Calling setup() is optional, which is stated plainly, and the three options that have a visible effect are simple. The transparent option, false by default, sets whether the background is set at all, so turning it on leaves the background unset for a terminal with its own. The bold option, true by default, is a global switch for bold, and the italic option, also true by default, does the same for italic. The comments in the source are worded as instructions rather than descriptions, that is if true the background is not set and that you can disable bold globally, which is a small thing but it tells you the flags are meant to be flipped rather than feared. The on_highlights callback is the fourth entry and it is the interesting one, because it is how you get at individual highlight groups.

on_highlights, and the two ways to use it

The Overriding highlights section explains the callback in two sentences. The first argument is a table of all the current highlight definitions that can be directly modified, and the second argument is a table of the theme colours. That gives you two levels of control, and the examples show both. You can replace an entire highlight group, defining hl.NewHighlight with a foreground, a background and bold, and the comment points at the nvim_set_hl documentation for the available options. Or you can change just the foreground of an existing group, setting hl.ExistingHighlight.fg to the colour you want, which in the example is the delta colour. Because the colour table is passed in as the second argument, the callback can refer to the theme's own names, so an override stays consistent with the rest of the palette rather than introducing a colour that appears nowhere else.

on_highlights = function(hl, colors)
  -- Replace an entire highlight group.
  -- See `:h nvim_set_hl()` for available options.
  hl.NewHighlight = { fg = colors.fg, bg = colors.bg, bold = true }

  -- Change only the foreground color of an existing group.
  hl.ExistingHighlight.fg = colors.delta
end

The repository layout, and the extras for other tools

The top level of the repository is small, with a LICENSE, a README, a .mailmap, a .stylua.toml for formatting the Lua, a colors/ directory and a lua/ directory. The split between them is the standard one for a Neovim colour scheme, where the colours directory holds the highlight definitions and the lua directory holds the module with the setup function and the palette. The Extras section points to a GitHub organisation, vague-theme, for extra colour configurations for other tools, so the same palette is available outside Neovim, which is a nice touch for someone who wants the editor and the terminal to match. The .stylua.toml tells you the project formats its Lua with StyLua, and the .mailmap is the kind of file a project with more than one contributor adds to keep author attribution stable through renames.

Who this suits, and what a version 2 means for a theme

The honest framing for a colour scheme is that it is a taste decision, and the interesting question is what the design decisions imply for daily use. A low contrast theme with a comment colour at #606079 against a #141415 background is comfortable to read for a long session, and the pastel but vivid syntax colours sit in the middle of the range rather than at either extreme. The palette is exposed as names, and the whole configuration surface is three flags plus a callback, so the theme is meant to be adjusted rather than accepted as shipped. The version line at 2.1.5 with releases across 2026 says it is being maintained. A reader deciding should look at the colours table rather than the preview image, since a screenshot taken on a calibrated screen in a dark room tells you very little about how the theme behaves on the display you actually use.

Editorial conclusion

Vague suits a Neovim user who wants a dark theme with muted contrast and a palette exposed as plain names rather than hidden inside a highlight table, and who will happily adjust a colour or two rather than accept a theme as shipped. It is the wrong choice if you want a theme with a large set of extra plugins and filetype work already done, because this repository is a colourscheme and nothing else, and a poor fit if you are on Neovim older than the version with the pack API, since the documented install is vim.pack.add. Before adopting it, read the colours table rather than the preview screenshot, because the theme is deliberately low contrast and that will matter more to you on a bright screen than any rendering will show.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vague-theme/vague.nvim on GitHub