lucario: one flat colour palette spread across two dozen editors and terminals

One palette, then a file per application

Lucario is not a plugin. It is a repository of theme files, one per application, all derived from the same six colour palette. The README presents the palette as a table with hex, RGB, HSL and a swatch image per entry: Background `#2b3e50`, Current Line `#243443`, Selection `#19242f`, Foreground `#f8f8f2`, Comment `#5c98cd`, String `#e6db74`.

The repository layout follows from that. There is a `colors/` directory holding the Vim colour file, `Lucario.tmTheme` at the root for Sublime Text, `Xcode/` for the dvtcolortheme file, `jetbrains/` for the JAR, `helix/`, `rio/`, `zed/`, `iterm/`, `termux/`, `terminal/`, `windows-terminal/`, `alacritty/`, `mintty/`, `xfce4-terminal/`, `xterm/`, `gnome-terminal/`, plus `CSS/`, `pygments/`, `styles/` and `geany/`.

The primary language of the repository is Vim Script, which tells you where the canonical implementation lives. Everything else is a port of the same palette into a foreign format, and each port has to be maintained by hand when the palette changes. That is the central trade-off of the project: consistency of appearance across many applications in exchange for one file to update per application.

Vim is where the theme actually lives

The Vim installation is the simplest of the set and the best starting point, because the file is copied into your own colour directory and then referenced from your vimrc. Download `colors/lucario.vim`, move it to the `~/.vim/colors/` directory, then add three lines to your vimrc:

    syntax enable
    set number
    colorscheme lucario

The README also gives an OS X hint of `vim /usr/share/vim/vimrc` for locating the system vimrc.

This is the version that other ports are derived from, so if you are unsure whether the palette suits your eyes, testing it in Vim costs one file copy. The other applications follow the same pattern in spirit but none of them is a two-line change: each requires you to fetch a file from a specific path in the repository and put it where that application expects it.

Editors that need a manual file drop

Three editor targets have no package manager path in the documentation, and each has its own ritual.

JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, PHPStorm and RubyMine) take a JAR. Download `Intellij/Lucario.jar`, then use File -> Import Settings, point the Import File Location dialog at the downloaded JAR, and in Select Components to Import choose only Editor Colors so the import does not overwrite your other IDE settings.

Sublime Text has both routes but they are manual. Package Control lists the theme as Lucario Color Scheme and can install it, but the documented manual route is to download `Lucario.tmTheme`, open Preferences -> Browse Packages, and drop the file there, then select it under Preferences -> Color Scheme -> Lucario.

Xcode takes `xcode/Lucario.dvtcolortheme` into the Xcode FontAndColorThemes directory, then Fonts & Colors to pick it. The README suggests moving the file with a single command:

$ mv Lucario.dvtcolortheme ~/Library/Developer/Xcode/UserData/FontAndColorThemes/

After that you reopen Xcode, open Xcode -> preferences and choose the theme on the Fonts & Colors tab. Note the path is the macOS user data location, so the procedure is specific to that platform.

VS Code ships as two third party ports

Visual Studio Code is the interesting case, because the repository does not itself contain a VS Code extension. The README says there are two implementations of Lucario for VS Code, one by Ikuyadeu with issues tracked in the Lucario-vscode repository, and one by victor-gp with issues tracked in the lucario-vscode-theme repository.

Installation goes through the Quick Open palette with Ctrl+P, where you paste one of two commands:

ext install Ikuyadeu.lucario
  OR
ext install victor-gp.lucario-theme

Two consequences follow. First, a VS Code user is not tracking this repository's changes directly; they are tracking one of two separate extensions, and support for a future palette change depends on that extension's maintainer. Second, the choice between them is made by appearance rather than by install instructions, since the documentation gives the same two commands and two preview images side by side.

Other editors take the theme as data rather than as an extension. Helix copies `helix/lucario.toml` into `$XDG_HOME/.config/helix/themes` and either issues the `:theme lucario` command or sets `theme = "lucario"` in `config.toml`. Rio creates a `themes` folder inside its configuration folder, moves `rio/lucario.toml` in, and points at it from the config file:

    [style]
    theme = "lucario"

Zed is documented as a local dev extension: run `zed: install dev extension`, select the `zed/` folder of the repository, then use `theme selector: toggle` (`cmd-k cmd-t`) to pick Lucario. The registry route is described as available once published, which is not the same as available now.

Terminal emulators mostly need a configuration snippet

For terminals the pattern is a TOML or snippet file per emulator, placed in that emulator's configuration directory. iTerm, Termux, Xfce Terminal, XTerm, Windows Terminal, Alacritty, Mintty and the `terminal/` directory each hold their own variant, and the same two-step applies: copy the file into the emulator's configuration folder, then reference it.

GNOME Terminal is the exception and needs a script. The README notes that it is not possible to add colour themes to GNOME Terminal, so the provided script creates a new Profile that uses custom colours. Download `gnome-terminal/lucario.sh`, run it from inside GNOME Terminal with `./lucario.sh`, right-click in the terminal and choose Profiles -> Lucario, then open Edit -> Preferences, go to the Profiles tab and select Lucario in the default profile dropdown. The script was created with terminal.sexy.

That workaround is the clearest illustration of what this repository is doing. Rather than insisting on native theme support, it generates a profile from a third party tool, so a terminal with no theming API still gets the palette. The cost is an extra moving part: the script writes profile configuration into your terminal setup rather than a single file you copy and delete.

The palette table is the only design document

There is no design rationale in the repository beyond the palette table and the screenshots. The README shows a colour per application, and each editor entry has an example image, so the practical guidance is visual comparison rather than written criteria.

What the palette implies can be read off the hex values. The background `#2b3e50` and current line `#243443` are the same hue at different lightness, with selection `#19242f` darker still. Comment `#5c98cd` and String `#e6db74` sit far apart in lightness and hue from the foreground `#f8f8f2`, so the two syntax classes that carry the most text are clearly separated from plain text. Whether that contrast ratio suits a particular screen is a question the screenshots cannot answer for you.

The design is therefore reproducible but not specified. If you fork the repository to change the palette, every variant file has to be regenerated by hand, and the README does not document a generator or a shared source of truth between the formats.

Licence, tags and a repository whose releases stopped in 2015

The licence is MIT, with the LICENSE file at the repository root and the same identifier in package.json. The package.json also names the project Lucario, sets the theme type to `syntax`, records the version as 2.2.0, and declares an Atom engine range of `>=1.0.0 <2.0.0`, which dates the metadata to the Atom era.

That is worth pausing on. The newest tagged release is v1.0.0 from 2015-06-30, with v0.1.9 and v0.1.8 both from July 2014, while the version inside package.json reads 2.2.0. Tags and the package version have drifted apart, so the tag list is not a reliable guide to the current state of the files.

On activity, the repository is not archived and the last push was on 2026-05-27. That is recent enough to show current work, but it comes with the caveat that no release has been cut in over a decade, so adopting this means copying files from the trunk rather than installing a pinned version. Anyone with strict reproducibility requirements should vendor the files they need instead of pointing a build at a branch.

Editorial conclusion

Adopt lucario if you want one visual identity across a mixed editor and terminal setup, and are prepared to maintain per-application theme files yourself. Do not adopt it expecting a package manager install path for every target, since JetBrains and Sublime Text are manual file drops, VS Code relies on two third party ports, and the Zed entry is documented as an extension registry item not yet published. Verify first that a variant exists for the application you care about, and note that the last push was on 2026-05-27 while the newest tagged release is v1.0.0 from 2015-06-30.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. raphamorim/lucario on GitHub
4. README
5. Releases