bluz71/vim-moonfly-colors for Neovim and Vim

Why moonfly targets both modern Neovim and classic Vim

moonfly solves a straightforward editor problem: assigning readable, consistent colors to syntax, diagnostics, language-server information, plugin interfaces, statuslines, and other Vim display elements. It is aimed at users who keep their editor appearance consistent across modern Neovim and classic Vim rather than maintaining unrelated configurations for each editor.

The repository supports more than basic syntax highlighting. Its Neovim-oriented definitions account for Neovim Tree-sitter, diagnostic output, LSP semantic highlights, Gitsigns, Neo-tree, Telescope, Noice, nvim-dap-ui, and other plugins. The shared list covers BufExplorer, Coc.nvim, CtrlP, fzf.vim, lightline, and vim-airline. Vim-specific entries include ALE, GitGutter, indentLine, NERDTree, Signify, and Tagbar. This makes moonfly relevant to configured editor installations rather than only a minimal syntax palette.

The scope is still a colorscheme. The README does not describe background processes, source transformation, formatting behavior, or text expansion. Its value lies in visual definitions for editor groups and supported integrations. Users looking for a complete interface kit, icon set, font package, or terminal palette should not treat this repository as a replacement for those components.

There is also a deliberate compatibility split. According to the README, Neovim highlights are implemented in Lua, while Vim highlights use legacy Vimscript. That makes cross-editor availability explicit, but it means the two implementations should not be assumed to share every group definition or future behavior.

moonfly's Lua, Vimscript, and plugin highlight architecture

The repository layout supports the README's description of two implementation paths. Directories such as `lua/`, `colors/`, `autoload/`, and `after/` are consistent with an editor colorscheme that exposes different loading paths for Neovim and Vim. The exact internal call sequence is not documented, so it would be speculative to claim more about loader behavior than the repository description establishes.

For Neovim, moonfly declares styling for Tree-sitter and LSP semantic highlighting rather than relying solely on older syntax groups. It also lists plugins that add virtual text, signs, diagnostics, file trees, pickers, status bars, debug interfaces, and notifications. These integrations matter because plugins often create their own highlight groups. A colorscheme that ignores them can leave interface elements visually disconnected even when ordinary syntax colors look correct.

The statusline model is more relaxed. moonfly has explicit configuration support for lightline, while the README states that vim-airline, lualine, linefly, and mistfly-statusline load their moonfly theme after startup. This means statusline support is presented as integration with each plugin rather than as a single statusline implementation supplied by moonfly itself.

Options alter several visual boundaries. Italics are enabled by default, terminal colors are enabled, undercurls are enabled, the cursor is not colored, transparency is disabled, and float windows are not given the normal popup background by default. The `moonflyWinSeparator` default is `1`. These switches allow adaptation, but they also increase the number of visual states that users may need to check.

Installing moonfly with lazy.nvim and enabling the first session

The README provides installation declarations for lazy.nvim, vim-plug, and Neovim `vim.pack.add`. The following tutorial uses lazy.nvim, then applies the theme in a Lua initialization file. The plugin declaration uses the exact repository name and maps it to the colorscheme name `moonfly`.

Add this plugin declaration to the lazy.nvim configuration:

{ "bluz71/vim-moonfly-colors", name = "moonfly", lazy = false, priority = 1000 },

The `name = "moonfly"` setting makes the installed plugin name available to the colorscheme command. The example explicitly disables lazy loading, so the declaration is available during initialization.

Enable moonfly after declaring the plugin:

-- Lua initialization file
vim.cmd [[colorscheme moonfly]]

Restart Neovim or reload the edited initialization file through your normal workflow. The visible result should be the dark charcoal palette shown in the repository screenshot, subject to the terminal's true-color support. The README does not provide an automated verification command, so confirmation is visual rather than based on a reported test procedure.

For Vim users using vim-plug, the README instead gives this declaration:

Plug 'bluz71/vim-moonfly-colors', { 'as': 'moonfly' }

Then enable the same colorscheme name from a Vimscript initialization file:

" Vimscript initialization file
colorscheme moonfly

The Vim command remains the same because the Vimscript theme definition is shipped with the repository. The implementation behind it is legacy Vimscript rather than the Lua path used by Neovim.

True-color terminals and moonfly's display constraints

The strictest requirement is explicit: moonfly is a true-color-only colorscheme. It requires an up-to-date Vim or Neovim running in a true-color terminal or a GUI client such as gVim. This rules out assumptions about reliable appearance in older terminal environments, restricted remote sessions, or configurations that do not support 24-bit color.

This limitation is narrower but clearer than a general claim that a terminal may look different. moonfly does not present a reduced-color fallback in the documented options. If the surrounding terminal cannot represent the theme as intended, the repository offers no documented palette conversion path. A user whose workflow requires ANSI 16-color or extended 256-color output should confirm support before changing the active colorscheme.

The README also links to a repository section about true-color terminals, indicating that terminal configuration is treated as part of adoption rather than an incidental preference. Visual inspection is still necessary because a terminal application may support true color while the host terminal, multiplexer, or remote connection alters the path. The screenshot confirms the intended appearance, but it does not document every terminal configuration needed to reproduce it.

Transparent backgrounds are disabled by default through `moonflyTransparent`. Enabling that option may suit users who deliberately want the terminal wallpaper to remain visible, but the README excerpt does not describe contrast tests or behavior with every plugin. Popup backgrounds and menu styling also have separate options. These defaults give moonfly a defined base appearance, while optional transparency can shift contrast decisions to the user.

moonfly configuration choices and plugin-specific trade-offs

moonfly exposes settings through Vim global variables, with both Lua and Vimscript forms documented. For example, users who want a colored cursor can set the corresponding option before loading the colorscheme:

-- Lua initialization file
vim.g.moonflyCursorColor = true

For Vimscript, the documented equivalent is:

" Vimscript initialization file
let g:moonflyCursorColor = v:true

This option is disabled by default. Other documented defaults include enabled italics, enabled terminal colors, enabled undercurls, disabled transparency, disabled normal popup and menu backgrounds, and a window separator value of `1`. Changing many options at once can produce a result that no longer resembles the screenshot, so configuration should be checked against actual readability rather than treated as a formal color specification.

Plugin coverage is broad, but the README lists integrations without claiming compatibility versions for every plugin. It also separates Neovim-only, shared, and Vim-only support. This separation is useful during adoption because it shows where the theme's definitions are expected to apply. It is not a promise that every plugin release exposes the same highlight groups.

The alternatives within moonfly are direct configuration variants rather than separate themes. Users can keep an opaque background or enable transparency, retain or remove italics, enable or disable undercurls, and alter popup and menu backgrounds. Those choices address visual preference while preserving the central moonfly palette. They do not solve the separate problem of running without true-color support.

moonfly versus nightfly and editor-native defaults

The README identifies `bluz71/vim-nightfly-colors` as another dark theme maintained by the same author. That is the only project-specific alternative named by the documentation, and the excerpt does not explain nightfly's palette, implementation, plugin coverage, or true-color requirements. The responsible comparison is therefore limited: moonfly provides a documented dual Vim and Neovim theme with Lua and Vimscript implementations, a documented option set, and an extensive compatibility list. The documentation does not establish how nightfly differs in those areas.

An editor-native default is the practical alternative when true color, extensive plugin coloring, or moonfly's dark charcoal palette is not desired. It keeps the theme inside the editor's existing baseline, but the README provides no comparison showing how a default palette looks with Treesitter, LSP, diagnostics, or each listed plugin. Users choosing that route should not expect moonfly's documented integration list to apply automatically.

This limitation matters for procurement-style comparisons. Moonfly's list establishes declared support, not visual equivalence across two editors. Because Neovim and Vim load different implementations, screenshots from one editor do not prove that every highlight group appears identically in the other. A candidate evaluation should therefore include the editor, terminal, plugins, and options that will actually be used.

Maintenance, licensing, and adoption boundaries

The repository is not archived, and its last push was on 2026-09-03. It has no GitHub releases, so there is no documented release channel or numbered upgrade path in the repository data. The default branch is `master`, which matters when cloning the repository directly or tracking branch changes. Maintenance activity should be assessed through repository changes and commit compatibility, not inferred from release numbering that does not exist here.

The project uses the MIT License. That identifier permits use and modification under the license's conditions, but this article does not interpret those conditions as legal advice. Upgrade cost appears limited to reviewing changes to Lua and Vimscript highlight definitions, testing changed plugin integrations, and checking whether an option name or default has changed. The documentation does not provide a formal migration guide or support matrix.

For Neovim users with many highlighted plugins, moonfly offers a broad declared integration surface and explicit visual options. For classic Vim users, it supplies a separate Vimscript path and includes Vim-specific plugins. It is the wrong choice when true color is unavailable, when a reduced-color terminal palette is required, or when identical group coverage across Neovim and Vim is assumed without checking both paths.

Editorial conclusion

Adopt moonfly if your terminal supports true color and you use Neovim, Vim, or several of the plugins covered by its highlight definitions. Do not adopt it as a low-color terminal theme or expect uniform internals across editors, because its Neovim and Vim implementations differ. Verify true-color rendering, plugin integration, italic and underline behavior, and transparency on your actual terminal before replacing an existing colorscheme.

Frequently asked questions

Official sources

1. bluz71/vim-moonfly-colors on GitHub
2. Issues
3. License: MIT
4. README