Zaibatsu

[romainl]

Zaibatsu is liberally inspired by the so-called "neo-tokyo", "neon-noir", "cyberpunk", "vaporware", etc. a e s t h e t i c, as well as popular colorschemes like dracula, tokyonight, or onedark.

Here is the palette at the time of this writing:

Of note: the colors don't change much between GUI and 256c except for the grayscale ramp which gets a slight purple-ish hue in GUI. Because the darkest of these is used as Normal background, the GUI experience is more nuanced than in 256c: very dark purple background versus black background.

This is mostly to get feedback. It has become quite usable in GUI and 256c but there is a lot of work left for 16c and 8c.

The screenshots below are all taken in MacVim on macOS:

[habamax]

It looks complete to me in 16/256/gui. The vibe is there:

8c is not there yet I guess? Or is it just a BG issue?

[romainl]

16c is more or less functional but it needs tweaking. I didn't work on 8c so far.

[romainl]

OK, from lo-def to hi-def…

8c:

16c:

256c:

GUI:

[habamax]

8c statuslinenc, is it intended?

[romainl]

Intended? Yes. Satisfactory? No.

[habamax]

currently it looks not very good for a hor split:

What about this?

hi Statusline ctermfg=grey ctermbg=black cterm=bold,reverse
hi StatuslineNC ctermfg=black ctermbg=grey cterm=NONE

[neutaaaaan]

Documenting feedback I gave to @romainl in #vim :

The only 2 problems I have with zaibatsu after a cursory glance have to do with contrast: Type and Preproc are noticeably darker than the rest of the palette, and Preproc clashes pretty badly with Identifier in some contexts.

Type could be brought up from ctermfg=168 to ctermfg=205 (or I suppose any other shade of red with a similar perceived brightness).

Preproc at ctermfg=80 simply doesn't survive my usual torture test. It's very contrived, but I've found it to be a good indicator of whether Preproc would also survive being used very sparingly, as I've been trying to work around of a similar clash between Preproc and Statement in Iosvkem for several years now.

I should be able to take a closer look at it in the evening, the room I am currently sitting in is very bright.

[romainl]

@neutaaaaan I have made the following tweaks:

• Type is brighter
• Identifier is a bit brighter
• PreProc is more blue, making it easier to differentiate from Identifier
• Special is more green, making it easier to differentiate from Identifier
• The neutralX colors in 256c now have a purple-ish hue too. It is less subtle than in GUI because of how the 256c color cube works but it seems acceptable

Left: GUI, right: 256c

[neutaaaaan]

Identifier and Special are still hardcoded to 87 and 84 in your template and the resulting colorscheme, not that I can really tell the difference anyway.

I'm not crazy about the shade of blue used for PreProc, but I'm not crazy about any of the shades of blue that I tried either, and it's one of the more balanced ones, so I suppose it'll have to do. I assume the colorschemes you referenced have fairly similar issues ?
I'm staring at this right now but this specific shade of low-grade depression doesn't exactly remind me of a mighty dub, more so of being slightly hungover on a sunday morning, waiting for The Deliverator to show up, a very specific Manu Chao song being played on a loop somewhere in the neighbourhood.

Anyway, that's enough bikeshedding the yak's haircut for now.

[habamax]

Not sure if cursorline is too distinct in 256 compared to gui:

256

gui

[habamax]

Also StatuslineNC could be "more the same" between GUI and 256. In GUI it is grey, in 256 has some bluish tint.

[habamax]

Another thing to mention is DiffText + Cursorline:

[craigmac]

I love it. I'm made something similar for myself but nowhere near the quality of detail here, I'll be using it daily so feedback incoming as I use it.

Couple things:, I like doing hi! link CurSearch IncSearch, what are you feelings on that? Second, the g:terminal_ansi_colors seem too dark to use in Alacritty (with and without tmux). Have a look at the PS1 colors and if I run something like lazygit or tig the red is too dark, it seems like the colors 8-15 would work better as the 0-7 colors but that's not how it's done usually, the 0-7 colors being the bright versions.

[romainl]

@craigmac Thanks. Feel free to report any issue you might have.

I like doing hi! link CurSearch IncSearch, what are you feelings on that?

A link to IncSearch makes a lot more sense to me. CurSearch being linked to Search by default is a bit weird and Bram's performance concerns don't seem justified to me but we are kind of following default's pattern everywhere in the name of consistency.

the g:terminal_ansi_colors seem too dark to use in Alacritty (with and without tmux).

IIRC I allocated the ANSI colors right at the beginning but yeah, the hexadecimal value changed a bit in the meantime so the assignation is not good anymore. The dark red being very obvious.

I will fix that, thanks.

[romainl]

@habamax initially, StatusLineNC, ToolbarButton, and CursorLine were neutral gray in 256c and closer in brightness to their GUI counterpart. The current version tries to be closer in terms of hue (purple-ish) but it is at the cost of brightness similarity because of how the xterm color cube works. On one hand it brings the whole 256c look and feel closer to GUI but on the other hand the colors are clearly too bright.

I may keep the purple-ish hue for StatusLineNC and ToolbarButton but CursorLine is way too bright so it will probably go back to a dark neutral gray.

[neutaaaaan]

I rigged this up using #d70087 and #5f5ff, seems like they could work. @romainl Is the xterm vibe, with the screaming bright green, yellow and cyan next to that pale light blue on purpose ? I don't really trust the built-in terminal with any of this.

[habamax]

I may keep the purple-ish hue for StatusLineNC and ToolbarButton but CursorLine is way too bright so it will probably go back to a dark neutral gray.

That is okay to have purple-ish hue for those, I pointed out that you have it in 256c but not in GUI...

[habamax]

[romainl]

No, it's not just gray, it has a slight purple hue: neutral3 is #98929f.

[habamax]

No, it's not just gray, it has a slight purple hue: neutral3 is #98929f.

Oh, my bad, didn't check the actual value -- it just looked so regularly gray so I blindly assumed it is gray.

[craigmac]

Small nits (while using termguicolors):

Errormsg: readable but the contrast isn't great:

SpellBad and friends: can we use cterm=undercurl and or is that too risky? Docs say it will fallback to underline if it isn't supported, but I'm thinking of situations where maybe user is saying it's supported but did not provide the correct t_Cs and t_Ce values as suggested in :h underline-codes. I haven't tested whether Vim looks just assumes those are correct and you end up with no undercurls OR underlines, or what it does. I have the same questions about highlight-ctermul

[neutaaaaan]

@craigmac Interactions between vim and terminal emulators are just too finnicky to risk using undercurls. For example, the fallback doesn't work at all using tmux 3.3a running inside urxvt 9.31, but it works inside urxvt itself.

[romainl]

ErrorMsg

I switched Error to the error color (pure red) but forgot ErrorMsg. Will fix this ASAP.

undercurl

Indeed it doesn't work in lots of places and the fallback to underline isn't great either. We use it for GUI, though, where things are more predictable.

highlight-ctermul

Same story.

[romainl]

So I have made a bunch of tweaks:

• ANSI 1 and ANSI 4 are more legible in :term
• 256c: CursorLine is a flat dark gray
• 256c: This makes it possible to darken the other blue-ish "neutral" hues
• add proper StatusLineTerm/NC
• fix ErrorMsg
• fix ColorColumn bleedind through Folded

256c:

Now, what to do with that ugly cyan/darkcyan?

[romainl]

256c:

• the cyans are less jarring
• the greens are warmer, which helps differrentiatiing them with cyans

[romainl]

Do you think the background is purple enough in GUI?

[habamax]

@romainl it is enough purple for me

[habamax]

Another thing to check is QuickFixLine vs IncSearch: https://asciinema.org/a/XNu0mcn0kaaQE46XwQCmeN2BY

[craigmac]

I liked the old green, this one reads more sickly than neon to me, maybe because I'm just fond of that tmux green 😀 And was going to say about the background, I think I'd like it a little more purple, somewhere between the original background and this latest one so you can tell it's a dark shade of purple without having to look real close, like 10% lighter? I also don't want it to be obviously purple like Ubuntu terminal though

[romainl]

So…

• I shifted the GUI background a little toward blue, as well as the "neutrals" that are derived from it.
• I tried a bunch of slightly brighter values for the GUI background but it was always too bright for my taste. I think I will stop playing with the GUI background, now. If you find the time to experiment with alternative values (remember that neutral1-5 are derived from black), feel free to post screenshots.
• I handled the QuickFixLine vs. IncSearch business by making IncSearch "black" on white. After 30 minutes I couldn't find a better QuickFixLine and everything I tried broke in one way or another in 16c. The new IncSearch doesn't clash with QuickFixLine anymore and it looks basically the same across environments.
• I think that green will stay. Insisting on keeping it slightly blue-ish only causes race conditions with cyans and I don't want to go there again.

GUI:

256c:

FWIW, I tried zaibatsu in 16c with my decades-old custom terminal palette and I think it works pretty well (even if @neutaaaaan will find it too muted):

Even though I use the default xterm palette as a baseline when working on 16c, it can be useful to check with other palettes. That said, I dread the test with Solarized ;-)

[neutaaaaan]

This really goes to show color perception depends on the particular combination of eyeballs and display.

Special looks sickly green, bordering on yellow to me, and collides pretty badly withConstant

Using #87ff00 instead of #afff00 seems more balanced to me, without sacrificing the perceived brightness, or colliding with Preproc.

2 issues with the built-in term in gvim : That dark red just doesn't work, and the StatusLine is going to be mighty confusing for tmux users.

[romainl]

• Hmm… OK for #87ff00.
• I will see what I can do for the dark red in :term.
• I went with the default logic for StatusLineTerm, having no idea how to denote a :term or even if that makes sense. Should I simply link them to their non-term equivalent or is there a better strategy?

Regarding that dark red…

For reference, xterm's default (#cd0000):

The current version:

A brighter alternative, similar in perceived brightness to xterm's default:

Indeed, color is complicated.

[neutaaaaan]

I had written a much longer post about the terminal colors, but I think most of the issues I have with them stem from the reference palette being the brighter set of colors. I figure I might as well just try and do it "my way" sometimes tomorrow and see if any useful feedback comes out of that.

The new IncSearch doesn't clash with QuickFixLine anymore and it looks basically the same across environments.

The new IncSearch blends in way too much to really be useful if you're not actively looking for it.

[craigmac]

I see the point about IncSearch, I would say only fix it if it doesn't require altering coloring anywhere else, because I like where the GUI colors are at now. I'm still not loving :term colors, but it's usable now! I can't really explain what I'm not sold on, though. I'd like to use the colors outside of vim as well, for terminal emulator palette.

[habamax]

Am I missing the point? I have a different incsearch which standouts quite nicely:

Both in gui and 256c...

[habamax]

oh, I was one iteration behind...

White is ok to me.

[neutaaaaan]

After messing about with the terminal palette for a while, and coming up with something that I feel works a bit better, I believe the biggest issue with zaibatsu is having to work from a colorscheme that uses very bright colors down to the dark palette that the built-in terminal will always stick to in my experience.
Making the bottom half more balanced means fiddling with the top half too so both sets of colors don't feel completely divorced, and not only is the end result not that great because of the limitations inherent to the xterm palette, it probably doesn't really look like like zaibatsu as it is now.

Would such a disconnect be acceptable ?

All of my experimenting made me realize that :term handles bold/bright by using a bold typeface, which can't be assumed to even exist, whereas the bright colors can be relied on. What this means, is that the top half of the palette is never seen, which in the worst case scenario means information loss, but in the case of zaibatsu means :term effectively hides most of the disconnect I mentionned before. Has this been brought up before ?

[romainl]

Of course having a :term palette that closely matches the colorscheme's palette would be perfect but I am definitely open to having some differences if that means more usability.

[neutaaaaan]

Here's the results after a few passes through the grinder.

This seems too much like quiet too me. Maybe working from an only slightly tamed bright palette down to a slightly brightened dark palette would turn out better.

[habamax]

@romainl what about this difftext?

[romainl]

FWIW, this is the current "main" palette:

@neutaaaaan, could you post the values you used for the latest screenshot? I would like to see if we can meet halfway :-).

@habamax, it might work in GUI because of the definition but I doubt it is going to work in 16c, for example.

To be honest, I am not super happy with that diff and most importantly how CursorLine interacts with DiffAdd and friends. It works incredibly well in 16c but not at all in 256c and GUI. Bummer.

[habamax]

@romainl that is actually quite ok:

[romainl]

@habamax I don't like it.

Let's backtrack a little…

• Without cterm=reverse, DiffAdd and friends are eaten away by CursorLine, which makes it hard to figure out if the cursor is in a diff and so on.
• With cterm=reverse, the background color of DiffAdd and friends stays so we always have the diff context, which is the most important info in a diff, but the "reverse" bit is also applied to CursorLine so the actual effect is: the correct bg from DiffX + the bg of CursorLine for fg.
• It works if the fg of DiffX is already either the same as CursorLine bg or something closer.
• It doesn't work if they are too different because the fg change might make it less legible.
• In my own accessible diff colorscheme, the fg of DiffX is dark so the effect of CursorLine is either invisible or negligible.
• In the default diff colorscheme, the fg of DiffX is light so the effect of CursorLine is too pronounced and I find it jarring.

FWIW, this made me spot a couple of issues in my own colorschemes. BRB.

[habamax]

It is not very appealing, but at least it became readable.

For wildcharm I use:

And it let me see the Difftext in CursorLine.

[neutaaaaan]

@romainl Highlighting moshe instead of @neutaaaaan is one hell of a fingerslip.

black: #0e0024 
darkred: #d7005f 
darkgreen: #00af5f
darkyellow: #d78700
darkblue: #5f5fff
darkmagenta: #d700ff
darkcyan: #5fd7ff
darkwhite: #d7d5db
grey: #878092
brightred: #ff0087
brightgreen: #00d700
brightyellow: #ffd700
brightblue: #8787ff
brightmagenta: #ff87ff
brightcyan: #00ffff
brightwhite: #ffffff

I reckon darkgreen, darkcyan, and maybe even darkyellow can be salvaged, but I probably pushed down too hard on the bright colors.

[romainl]

In the last commit…

• background is transparent for 8c 16c and 256c
• StatusLineTerm/NC is now a link to StatusLine/NC
• VisualNOS is more readable
• small tweaks

The biggest change is the background. My idea is that zaibatsu is meant to have a dark purple-ish background, something that can only be achieved in a declarative way in the GUI or in a termguicolors-compatible terminal. In other cases (8c, 16c, 256c w/o termguicolors) I wonder if it is justifiable to make it transparent and let crafty users adjust their terminal's background as they see fit.

The screenshots below are taken in a 256c terminal emulator. The first one uses my default terminal's background, a dark gray, the second one uses pure black, the third one uses the same color as the GUI version, the last one is a bit on the insane side of things.

What do you think?

[habamax]

What do you think?

We have no colorschemes with transparent bg in the repo. Imagine transparent peachpuff on a black terminal or transparent zaibatsu on a gray/white bg terminal.

[neutaaaaan]

I'm not crazy about the idea either, it's bound to generate false positives.

[romainl]

OK, reverted.

[habamax]

Spent a day with zaibatsu, looks good to me.