gruvbox-community / gruvbox-contrib

Ports of the gruvbox colorscheme
125 stars 17 forks source link

Canonical colour list #32

Open markembling opened 1 week ago

markembling commented 1 week ago

Not really sure this is an issue as such, but I'm trying to understand what should be considered the canonical list of colours for gruvbox (particularly in the context of making additional gruvbox-based themes or similar).

I'm aware this is a fork of the original gruvbox repo so let me know if this issue is better directed there, but hopefully you can answer within the context of these forked repos.

This repo has the color.table file which appears to act as a canonical list. However I'm not entirely sure I understand the contents (is this a file format I'm not familiar with, or something specific to this repo?)

Would it be appropriate to use that as a canonical list, or would it be more appropriate to treat the palette images from the main gruvbox repo as the canonical list?

If the former is the case, is there a method for deriving the original dark/light palettes (inc. contrast variants) from the table file? I can see how some of it hangs together but not all. If there's some kind of reference for the file (or, as I said before, if this is a file format I've just failed to find details of), that would be really useful to know.

If the latter is the case, is there a machine-readable/textual representation or would it be a case of just transcribing the colours off the images.

Appreciate any help or info you can give me.

rbong commented 1 week ago

The closest thing we have right now (I think?) is the palette section in the readme. If someone wants to translate these images into a machine-readable file, I'd accept a PR.

markembling commented 1 week ago

I'd be happy to take a look at doing that.

Would we expect to see duplicates like in the images?

For example, the same gray is added twice (for some reason) - it seems redundant to duplicate it, but maybe there's a reason for that?

Also, taking the dark theme as an example, fg and fg0 and bg and bg0 are the same colours but with different names. Would we expect both entries to be included as they are in the image?

rbong commented 1 week ago

Check out the numbers on the top left/right of the cells. The top right number is the 16-color terminal ID of the color, the top left number is the 256-color terminal ID (not supported by all terminals).

So the top 16 colors are the basic colors. They're also available as alternative 256-color IDs if it's supported by your terminal, which is pretty common.

The bottom 16 colors are the alternative/extended colors. The black, grey, and white basic colors are included just to provide a complete gradient of the foreground/background colors that are available.

rbong commented 1 week ago

I checked it out and the color.table file used to be colortable.md. So it turns out it's a made up format, or at least it replaced a more useful format. I would much rather change it back to markdown since it is human-readable and is properly formatted in GitHub, perhaps with more context as well.

markembling commented 1 week ago

Thanks, that's all useful info, appreciate it. I figured the numbers were significant in a terminal context but wasn't sure how (the specifics of terminal colours aren't really my expertise) so that really helps. Interesting to learn about the file rename too.

It seems to me like we could benefit from having something properly machine-readable (JSON?) which could then theoretically serve as a base for all of the rest. I.e. could be used to derive other palette/theme files or human-readable formats including Markdown maybe.

I'm guessing this repo is probably the right place for it since the actual gruvbox repo is specific to the Vim theme implementation.

Theres still some strangeness insofar as the palettes in the readme are treated as two distinct ones (dark and light) but the color.table file sort of lumps them all together but doesn't seem to carry quite enough info to extract a full copy of both palettes from it.

I'll have a think and hopefully send some pull requests your way when I have a little bit of time. In the meantime, any more thoughts you might have would probably help too.

rbong commented 1 week ago

If you want to tackle the machine-readable file and/or the human readable file be my guest - either/both are useful. What isn't useful is what we have now, which is neither human or machine readable. At least I think so - there's still the possibility that color.table serves some unknown purpose - but then why was it a markdown file before? I also think light/dark should be separated.

This repo is the right place for it, correct.