feat: add retrobox a remake of gruvbox8

[habamax]

Port gruvbox8 from @lifepillar

• Name -- should we keep it or change it to something different? (if it is "to keep", is @lifepillar ok with this?)
• Only a single "default" gruvbox8 was ported (no hard/soft variants)
• No italics
• No filetypes hl
• No plugins hl

termguicolors

256

16

8

[romainl]

The white background is not achievable in 8c?

[habamax]

The white background is not achievable in 8c?

I don't think so, unless user redefine grey/7

[romainl]

And 15 can't be used?

I'm asking because yellow on gray (assuming Xterm defaults) for the messages doesn't work very well.

Also, in 16c dark, visual selection would probably work better with white fg. In 16c light, fg would work better if it were black, IMO.

[habamax]

And 15 can't be used? It works for terminal emulators (Xterm) but probably not for the linux tty (or whatever it is called)

Xterm

And yeah, it doesn't work for the terminal in CTRL-ALT-F3

I'm asking because yellow on gray (assuming Xterm defaults) for the messages doesn't work very well.

I can change it to some other color, black?

Also, in 16c dark, visual selection would probably work better with white fg. In 16c light, fg would work better if it were black, IMO.

Will change this too

[habamax]

what about gruvbox7 ?

[romainl]

What would the 7 refer to?

Besides, what's the stance of the @lifepillar about this? Maybe your changes could be merged in his version and we could "officially" get gruvbox8?

[habamax]

What would the 7 refer to?

gruvbox8 with less features. But I am bad with names.

Maybe your changes could be merged in his version

I don't thinks so, I have removed quite a few things:

• lightline/airline support
• ftplugins/plugins
• italics
• settings

[neutaaaaan]

Seems like a perfectly fine remake overall.
Found a couple issues with the light 8c version: comments aren't highlighted at all, and Todo uses the ctermfg=0 cterm=bold hack to be rendered as color8, which should usually work and degrade down to something legible but isn't guaranteed to do so. This being a new colorscheme instead of a legacy one, I believe we should be free to at least use bold. Quiet and Lunaperche both do, for example.

As for the name, considering that this is ultimately going to be shipped with vim as opposed to wittingly installed by the user, we should do our best not to use the original name, or something that could reasonably be expected to cause confusion. If it were solarized or jellybeans, we could get away with something derivative such as sunitized or gummybears, but in the case of gruvbox I don't have a clue. Given that the original gruvboxhas some fairly brittle implementation issues, I joked in irc about using lamentconfiguration in reference to the puzzle box in the first Hellraiser movie, but the reference is obscure at best.

[habamax]

Renamed to retrobox and fixed some of 8c colors issues.

Not sure about TODO though.

[lifepillar]

Late to the party, but hopefully not too late. I like retrobox. I think it is better to use a different name than gruvbox/gruvbox8. Partly for the already mentioned reasons, and partly because a different name means that one should not expect a perfect port (possibly avoiding a flood of questions such as «Where are the “hard”/“soft” variants? Where has italics gone? Why is my filetype highlighted differently from the original?» etc…). Besides, that frees you from being faithful to the original. In fact, I would encourage you to modify the color scheme a bit. For example, I personally like the 256-color “hard” dark variant more than the normal one, and the true-color “light” variant more than the normal one. Maybe the optimum is something in between.

Btw, Spell* highlight groups still have italics.

[habamax]

@lifepillar thx, I missed those italics.

As for hard/soft -- if @romainl and @neutaaaaan would also +1, will change it as requested. I don't have my own preference here.

[habamax]

and the true-color “light” variant more than the normal one

Did you mean soft "light"?

[habamax]

Although red in "hard" looks better...

[romainl]

Honestly, I don't like Gruvbox or any of its clones so it is up to you, @habamax.

[habamax]

Colorcolumn, Folded, StatuslineNC, Cursorline have to be changed I think:

[habamax]

Visual, Folded, StatuslineNC, Cursorline and ColorColumn:

[neutaaaaan]

The background choices for the 256c and gui versions seem fine to me as they are now. If anything I'd be worried about making the light background versions any softer as the overall color separation isn't the best to begin with.

I'm very much in the same boat as @romainl : I've never been much of a gruvbox person, but it's always been there as a good enough fallback when necessary. Trying to put myself in the shoes of an end user, it feels like retrobox deviates too much from what I believe to be gruvbox's identity (the italicized strings, the rewiring of specific elements) but I'm also aware of the fact that I'm effectively bikeshedding the yak's haircut by saying this.

[habamax]

I guess I am done with retrobox, if there are no more comments -- it is ready.

[romainl]

I'm having my machine replaced with a new one today so I won't be able to test this thoroughly before this week-end. That said, after all these years, I still find that background hack to have "light" and "dark" colorschemes gross.

[romainl]

So, after a couple of hours with the dark version in 256c…

• TabLine lacks contrast,
• IncSearch is too close to Search.

[habamax]

So, after a couple of hours with the dark version in 256c…

* TabLine lacks contrast,

* IncSearch is too close to Search.

What about statusline vs statuslineNC?

[romainl]

What about statusline vs statuslineNC?

They are fine.

[habamax]

[habamax]

and light

[romainl]

Hmm, we are not seeing the same thing.

This is what I see, before your latest changes:

• StatusLine and StatusLineNC are both fine: legible and well contrasted.
• TabLine is too dark and TabLineSel is too muted.

Somewhat, StatusLineNC is worse in your last screenshots and TabLine is still too dark.

[habamax]

Have you tried the latest commit?

[habamax]

Oh I see what you mean, orangish statuslineNC? they were different in gui and 256 so I have aligned them using gui version

[habamax]

notermguicolors (256)

termguicolors

[habamax]

@romainl what about this?

[romainl]

what about this?

I like it better, yes.

[habamax]

@romainl pls check updated

[habamax]

for light version though, I couldn't come up with the same statusline -- whatever non black fg I use it looks bad.

[habamax]

@romainl note that gui version has "slightly" different colors

[romainl]

How "slightly different" are they?

[habamax]

How "slightly different" are they?

Not too much and in general it feels the same.

[romainl]

Oh, I see…

Light 256c and GUI are indeed different but they seem internally consistent to me. Dark 256c and GUI appear the same to me.

I think we can go forward with that one.

One comment, though: I don't see how dark and light are related. They work, but they seem disconnected to me, which is a common theme among those dark/light colorschemes… and a problem already present in the original anyway. The light one is rarely a "light" version of the dark one and the other way around and that is something that have been bothering me for a long time. Like… Solarized dark and light shared a palette so there definitely was a "technical" connection between the two, but they had such a different feel that they should have been two colorschemes, which would have made them less brittle and less drama-inducing to begin with.

I'm relatively confident that our colorschemes are less brittle than those, but I can't shake the feeling that that :set bg=light/dark trick has never been used correctly and the light version/dark version concept rarely, if ever, executed convincingly.

[habamax]

One comment, though: I don't see how dark and light are related. They work, but they seem disconnected to me, which is a common theme among those dark/light colorschemes… and a problem already present in the original anyway.

Indeed.

I think we can go forward with that one.

Let's make it in.