Automatic 256 palette generation

[jake-stewart]

Hi Kovid,

I use and love the 256 color palette:

• Unlike base16 alone, it doesn't suffer from such a limited palette.

• Unlike truecolor, you can change your 256 palette in one place and all your
  terminal programs stay synchronized. This includes light/dark theme
  switching.

The 256 palette is the perfect middle ground between consistency and
flexibility, yet it remains greatly overlooked.

People love base16 because it just works, but TUI programs like Vim need more
variation than 16 colors can provide. Since the default 256 palette clashes
with their base16 theme, they resort to truecolor. Nobody wants to manually
define 240 extra colors.

I wrote a script that generates the full 256 palette from a set of base16
colors. This makes the 256 palette completely practical, beautiful, and
consistent.

Although this solves my problem, I believe there's a larger problem to solve.

The 256 palette is almost completely disregarded. By default it looks ugly and
inconsistent when paired with a custom base16 palette, so people avoid it in
favor of truecolor.

Terminal program developers know this, so they too avoid 256 color in favor of
either simple base16 palettes or truecolor themes that clash with the rest of
your environment.

If by default the 256 palette were automatically generated based on the user's
base16 colors, terminal programs would actually use them, gaining flexibility
without sacrificing theming.

We would escape the future where every editor ships its own default theme and
gain true light/dark mode switching.

How would you feel about a PR that automatically generates the 256 palette
based on the user's base16 colors? This generation would only occur if the user
hasn't defined any of the 256 colors manually and could be disabled with a
config option.

[kovidgoyal]

On Fri, Jan 23, 2026 at 03:12:54AM -0800, jake-stewart wrote: Hi Kovid, I use and love the 256 color palette: - Unlike base16 alone, it doesn't suffer from such a limited palette. - Unlike truecolor, you can change your 256 palette in one place and all your terminal programs stay synchronized. This includes light/dark theme switching.

Note that light/dark switching can and does work with truecolor as well. Modern terminals have the capability to notify TUI programs of light/dark preference and changes. nvim for example supports this, IIRC. The kitty diff kitten definitely does.

The 256 palette is the perfect middle ground between consistency and flexibility, yet it remains greatly overlooked. People love base16 because it just works, but TUI programs like Vim need more variation than 16 colors can provide. Since the default 256 palette clashes with their base16 theme, they resort to truecolor. Nobody wants to manually define 240 extra colors.

The full 256 color palette can be set by TUI programs not just the 16 colors. I dont quite follow your argument here, if no one wants to write 240 colors manually they certainly dont want to write 16 million colors manually. IME truecolor is most useful in editors for syntax highlighting, mostly because the syntax highlighting tends to be ported from other libraries/context where truecolor is the default.

I wrote [a script](https://github.com/jake-stewart/color256) that generates the full 256 palette from a set of base16 colors. This makes the 256 palette completely practical, beautiful, and consistent. Although this solves my problem, I believe there's a larger problem to solve. The 256 palette is almost completely disregarded. By default it looks ugly and inconsistent when paired with a custom base16 palette, so people avoid it in favor of truecolor. Terminal program developers know this, so they too avoid 256 color in favor of either simple base16 palettes or truecolor themes that clash with the rest of your environment. If by default the 256 palette were automatically generated based on the user's base16 colors, terminal programs would actually use them, gaining flexibility without sacrificing theming. We would escape the future where every editor ships its own default theme and gain true light/dark mode switching. How would you feel about a PR that automatically generates the 256 palette based on the user's base16 colors? This generation would only occur if the user hasn't defined any of the 256 colors manually and could be disabled with a config option.

In principle, sure, but the devil is in the details. In particular, there isn't really a mechanism in kitty's config machinery to know if a setting has come from the user or the defaults beyond just comparing it with the defaults. And the performance matters as it affects startup time. I could say more looking at an actual PR.

[jake-stewart]

Thanks for the quick response.

Note that light/dark switching can and does work with truecolor as well. Modern
terminals have the capability to notify TUI programs of light/dark
preference and changes

I apologise. I was thinking from my point of view where I configure some
program using hex codes vs 256 palette indexes. You are right that truecolor
can support theme switching with some extra effort.

The full 256 color palette can be set by TUI programs not just the 16
colors. I dont quite follow your argument here

When a terminal program writes some coloured text, they have two options:

1. They can write some text that is generally red. They do not care about the
   specifics, only caring that it is red. In this case, they use the base16 color
   palette as it allows the user to decide how they want red to look.

2. They can write some text that is specifically red. They could use
   truecolor and write #ff0000 exactly. This is less ideal since it takes away the
   user's preference (and looks quite ugly/inconsistent).

The 256 palette is defined like so:

• Base16 colors.
• 6x6x6 color cube.
• 24-color greyscale ramp.

A terminal program may want to write text on a faint red background. They could
use the 6x6x6 color cube and calculate the 256 palette index using R=1, G=0,
B=0. This colour would be generally faint red, consistent, and easily
configured by the user.

Except that it is not consistent by default since the 256 palette does not
align with the user's base16 palette. The first shade of red in the 6x6x6 cube
is always #5f0000, which clashes with every theme. Terminal programs avoid
using 256 color as a result.

If instead the 256 color palette was interpolated between the user-defined
background, foreground, and base 8 colors, terminal programs would be more
likely to use it and gain a lot more flexibility.

In principle, sure, but the devil is in the details. In particular,
there isn't really a mechanism in kitty's config machinery to know if a
setting has come from the user or the defaults beyond just comparing it
with the defaults. And the performance matters as it affects startup
time. I could say more looking at an actual PR.

I will think more about this. I was mainly concerned whether an effort would be
wasted. I understand you seem open to the idea and would consider it further
once fleshed out.