Open-source project
jacoborus/tender.vim avatar
jacoborus/tender.vim

tender.vim is a 24-bit colorscheme that also carries statusline themes

A 24bit colorscheme for Vim, Airline and Lightline

1,275 stars82 forksVim ScriptMIT

At a glance

What is it?
tender.vim is a Vim and Neovim colorscheme by Jacobo Tabernero, generated from a YAML definition by Estilo, and it ships matching themes for the Airline and Lightline statusline plugins. It fits a Vim user who wants a dark 24-bit theme with a coordinated statusline, and it does not fit a team that needs a light theme or a generated set of colour variants on demand.
Who is it for?
tender.vim fits a Vim or Neovim user on a terminal with true colour support who wants one dark palette covering syntax highlighting, statusline and the surrounding terminal, and it does not fit a workflow that needs a light variant or that runs on a terminal limited to 256 colours.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Activity is slowing. The repository last received commits 6 months ago.
What is it written in?
Mainly Vim Script, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The colorscheme is generated, not hand-written

tender.vim is described as a 24bit colorscheme for Vim, Airline and Lightline, and the second half of that sentence is the differentiator. Most colorschemes style syntax highlighting and leave the statusline alone, so a Vim user with Airline or Lightline ends up with a purple statusline bolted onto a carefully matched editor theme.

The important structural detail is that the colorscheme is generated. The README states it is generated by Estilo, the author's own tool, and the repository layout confirms it: there is a estilo.yml file, a estilos/ directory, a colors/ directory and an autoload/ directory alongside the README, LICENSE and .gitignore. The workflow is a YAML definition of the palette that is compiled into Vim script.

That has an obvious benefit for the maintainer. A palette is a set of named colours with relationships, and expressing it as data rather than as a wall of let g:color_ statements means a change to the palette is a change to one file rather than to hundreds of highlight definitions. It also means the generated output is consistent by construction, since every group draws from the same named palette rather than from colours picked one at a time.

The cost is that the colourscheme is not something you would edit by hand in a fork, at least not sensibly. If you want a different palette, the right place to start is estilo.yml and the tool that consumes it, not the generated file in colors/.

The project is MIT licensed, copyright 2016 Jacobo Tabernero, and the last push was on 2026-04-27.

24-bit colour is a requirement, not a preference

The colourscheme is 24-bit, and the installation instructions make clear that this depends on the editor and the terminal cooperating.

The recommended config block is:

vim
" If you have vim >=8.0 or Neovim >= 0.1.5
if (has("termguicolors"))
  set termguicolors
endif

" For Neovim 0.1.3 and 0.1.4
let $NVIM_TUI_ENABLE_TRUE_COLOR=1

" Theme
syntax enable
colorscheme tender

The termguicolors option is what tells Vim to emit 24-bit colour sequences rather than the older 256-colour approximations, and the feature check means the line is harmless on an older editor, where the colourscheme will simply fall back to whatever the terminal can do. The Neovim variable is there for the two releases before Neovim had a termguicolors equivalent of its own, and it is set as an environment variable with the let $VAR form so it is exported to the child process.

This is a real constraint in practice. A colourscheme with 24-bit colours looks wrong, or washed out, on a terminal that only advertises 256 colours, and the fix is in the terminal configuration, not in Vim. There is no 256-colour variant of tender in the repository, and the README does not describe one.

The syntax enable line is worth noting too. A colourscheme defines highlight groups, and without syntax highlighting turned on, most of them have nothing to attach to. It is a small thing, but it is the kind of line that gets left out of a blog post about a theme and then wondered about.

Airline and Lightline each get a tender and a tenderplus theme

The statusline integration is where the README spends most of its configuration text, and the shape is the same for both plugins.

For Lightline the configuration is a single key in the plugin's own settings:

vim
" set lighline theme inside lightline config
let g:lightline = { 'colorscheme': 'tender' }

For Airline it is a theme name:

vim
" set airline theme
let g:airline_theme = 'tender'

Both plugins offer two themes, tender and tenderplus. The distinction between them is not described in the README, which is a gap: a user has to pick one and see which looks right. Given that both plugins build on the same base palette, the plus variant is presumably the version with more visual differentiation between statusline sections, but that is an inference and the documentation does not make the claim.

The mechanism differs slightly between the plugins, and that difference matters if you are wiring this up yourself. Lightline takes a whole options dictionary and you replace the colorscheme key inside your existing configuration, so you are editing a table you probably already have. Airline takes a single string naming a theme, and the themes are registered by the plugin's own theme files, so the colourscheme plugin and the statusline plugin are decoupled through a name.

Either way, the colourscheme alone does not restyle the statusline. If Airline is installed and g:airline_theme is not set to tender or tenderplus, the statusline keeps whatever it had, and the result is the mismatch the author built this to avoid.

The terminal side is handled by a family of community ports

A 24-bit colourscheme only looks right if the terminal's own background and foreground match it, and tender addresses that with a set of ports maintained by other people rather than by the project.

The list is in the README under Terminal themes. There is Tender Alacritty by @huyvohcmc, Tender xresources by @pebeto, Tender Blink Shell by @Rafaelcv7, Tender WezTerm by @kyoheiu, and Tender Kitty and Tender Mintty by @CompEng0001.

That is a small but telling piece of information. The author did not write the terminal themes, and does not maintain them; other users did, for the terminals they use. Each is a separate repository, so each follows its own update cycle, and an upstream change to the palette does not automatically reach them.

The practical consequence is that the visual coherence of a tender setup depends on three or four separate repositories being kept roughly in step. A user who installs the Vim colourscheme and the Alacritty theme from six months apart may find that the background of one does not match the background of the other, since nothing enforces synchronisation between the ports.

The xresources port is worth singling out because X resources work differently from a theme file. An X resources file is a set of server-wide settings that any X client can read, so it can set the terminal background once for every application, not just the terminal. That is a different scope of fix from a colourscheme file for one terminal, and it explains why it is a separate project with its own author.

Two edge cases the README documents, and a manual install path

Two specific problems are called out, and both are the kind that produce a support issue rather than a feature request.

The first is MacVim. The fix is one line:

vim
let macvim_skip_colorscheme=1

The README links issue 9 in the repository for the details. The option name suggests the cause: MacVim's own handling of the colourscheme conflicts with what the theme expects, and skipping that handling avoids the conflict. This is a workaround rather than a fix in the theme, and it is a reminder that a colourscheme is not always a purely passive file, since it can interact with editor-specific startup behaviour.

The second is a manual install for people without a plugin manager, or without a plugin manager that puts the colourscheme where Vim looks for it. The instructions are:

sh
cp ~/.vim/bundle/tender/colors/tender.vim ~/.vim/colors/tender.vim

The copy is needed because Vim only looks for colourschemes in the runtimepath, and a colourscheme sitting inside a plugin directory is not on that path unless the plugin manager adds it. The command as written copies the file into ~/.vim/colors/, and the README notes you may need to create the folder if it does not exist.

The plugin manager options are the usual three. vim-plug uses Plug 'jacoborus/tender.vim', NeoBundle uses NeoBundle 'jacoborus/tender.vim', and Vundle uses Plugin 'jacoborus/tender.vim'. All three refer to the same repository, jacoborus/tender.vim.

The screenshots in the README cover JavaScript, a statusline variant, the regular status, XML, a NerdTree YAML view, a git commit buffer and a GV diff, which is a fair sample of the surfaces a theme has to look right on: syntax, diffs, sidebars and the statusline.

Where tender.vim is the wrong choice

The first wrong-tool case is a terminal without true colour. The colourscheme is 24-bit by definition, and the repository ships no 256-colour fallback and no light variant. A user on a remote session over a plain connection, or on a terminal emulator configured to a legacy colour depth, will get approximations.

The second is a user who wants a generated palette family. Because the theme is a single generated file from one YAML definition, tender is one specific palette rather than a system with variants. A project that wants its own derived light theme, or a set of seasonal palettes, has to run Estilo and produce its own output, which is a different amount of work than picking a different colorscheme from a list.

The third is a Neovim user with a terminal statusline that has already been themed. The statusline integration is specific to Airline and Lightline. Other statusline plugins, or Neovim's built-in statusline, get nothing from tender beyond the syntax colours, and the mismatch the project exists to avoid is back.

The fourth, and the one that is easy to overlook, is the maintenance profile. There are no GitHub releases, and the last push was on 2026-04-27. For a colorscheme that is a much weaker signal than it would be for a library, because a colourscheme is a static artefact and a year-old one is usually still fine. But the terminal ports are separate repositories with separate maintainers, and if the palette changes in the colourscheme and the ports do not follow, the set drifts apart. That is the thing to watch, not the age of the Vim file itself.

Editorial conclusion

tender.vim fits a Vim or Neovim user on a terminal with true colour support who wants one dark palette covering syntax highlighting, statusline and the surrounding terminal, and it does not fit a workflow that needs a light variant or that runs on a terminal limited to 256 colours. Before installing, confirm your terminal reports true colour and that the plugin you use for the statusline, Airline or Lightline, is present, since the colourscheme alone will not restyle a statusline that is not configured to use tender.

Frequently asked questions

How do I install the tender.vim colorscheme?

Install it with a plugin manager, using Plug 'jacoborus/tender.vim' for vim-plug, NeoBundle 'jacoborus/tender.vim' for NeoBundle or Plugin 'jacoborus/tender.vim' for Vundle. Then set termguicolors, run syntax enable and colorscheme tender in your vimrc or init.vim.

How do I make the tender statusline theme work with Airline or Lightline?

For Lightline set let g:lightline = { 'colorscheme': 'tender' } in your existing Lightline configuration. For Airline set let g:airline_theme = 'tender'. Both plugins offer a tender and a tenderplus theme, and the colorscheme on its own will not restyle the statusline.

Does tender.vim work with true colour terminals only?

It is a 24bit colorscheme, so it needs a terminal that supports true colour, and the config enables it with set termguicolors guarded by a has() check. Older Neovim releases 0.1.3 and 0.1.4 need the NVIM_TUI_ENABLE_TRUE_COLOR environment variable set, and there is no 256-colour fallback shipped.

How is the tender.vim colorscheme produced?

It is generated by Estilo, the author's own tool, from a YAML definition. The repository holds estilo.yml, an estilos/ directory, a colors/ directory with the generated output and an autoload/ directory, so a modified palette would be changed in the definition and regenerated rather than edited in the generated file.

Official sources

  1. Issues
  2. jacoborus/tender.vim on GitHub
  3. License: MIT
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/jacoborus-tender-vim.svg)](https://hysenlabs.com/projects/jacoborus-tender-vim)

Was this useful?