Universal monochrome theme
I've worked a bit on that pure monochrome theme that would allow people to ignore a broken environment, and keep :syntax on without having to resort to setting t_Co=0 which quite frankly is the visual equivalent of vogon poetry.
Not defining anything but bold/underline/reverse and letting vim use your terminal foreground and background colors works just fine.
I'm relatively satisfied with what I've put together, although my own preference is to only highlight things that I feel I want to know, rather than try to be complete. There is some annoying overlap here and there, but it's fairly minimal.


The implementation itself is really nothing fancy, I've attached a version I hacked on top of another one of my themes if anyone feels like playing around with it.
Thanks.
From the top of my head:
-
I like it, it is very close to where I want bruin to go when I have time to iterate (it is too "rich", right now),
-
the active and inactive status lines are not easily distinguishable, I would suggest making one underlined (possibly the inactive one),
-
I think the UI should be treated with more consistency, like… the current tab and the current window looking the same, etc.,
-
some highlight groups are in a bizarre state where they inherit the messy default colors:
Identifier xxx term=underline ctermfg=6 guifg=DarkCyan Statement xxx term=bold ctermfg=130 gui=bold guifg=Brown PreProc xxx term=underline ctermfg=5 guifg=#6a0dad
the active and inactive status lines are not easily distinguishable, I would suggest making one underlined (possibly the inactive one),
I used to do that, but I'd often lose the inactive one below a fold, or a particularly dense line. reverse is consistent, and doesn't happen often outside of diffs.
I think the UI should be treated with more consistency, like… the current tab and the current window looking the same, etc.,
TabLineSel term=bold,reverse ought to do the trick. There are probably a handful more elements that I never get to see within my own workflow that need to be tweaked.
The generated file is messy, I expect it'll be rewritten from scratch if we make it past the bikeshedding stage.
Slightly updated version, with changes to how StatusLineNC and Tabs are handled. Can't shake the bizarre way groups inherit the default vim colours.
Win Terminal:

GUI:

Is there a way I can make it consistently either white or black for both? Should I do autocmd Colorscheme and set Normal fg and bg?
If you're talking about the way the windows terminal uses different colours for bold characters, that's precisely what I'd hoped to avoid by only relying on foreground/background, and all of my testing in xterm, urxvt and gnome-terminal came back fine. There's not fixing that without messing about with your local config.
If you mean you'd like to bolt the colours down, you'd have to explicitely set everything -- the inheritance chain can be downright bizarre at times -- and then you'd be pretty much guaranteed to run into problems specific to the local environment, such as the brighter bold colours, or bizarre colour combinations. I don't see any point in shipping that, the neutral version is virtually guaranteed to work fine, and one of the very few things that can be reasonably expected is that the user will have control over their terminal emulator. On the other hand, you might be interested by one of these colourschemes.
@neutaaaaan all vim shipped colorschemes are either dark or light no matter if I use them in terminal or GUI with the exception of default. (correct me if I am wrong).
The question was whether this one is dark or light? Or is it "default-like" that depends on background of a host (GUI white, terminal whatever is there)?
Or is it "default-like" that depends on background of a host (GUI white, terminal whatever is there)?
That's it. What it's set to effectively doesn't matter, the host process will force its own foreground/background regardless.
IMO, something like this should definitely be included, but sticking to pure monochrome in capable terminals and GUI seems a bit extreme to me. Are there any reasons for that? I'd prefer a color scheme that degrades gracefully:
- GUI/256/88 colors are available: use shades of gray;
- 16 colors: use ANSI 0, 7, 8, and 15;
- 8 colors: use ANSI 0 and 7;
- less colors: just set term attributes.
If, on the other hand, there are reasons to prefer pure monochrome everywhere, then the color scheme could be simplified. @neutaaaaan Could you make your template available, so we can experiment with this color scheme?
As I mentioned in https://github.com/vim/colorschemes/issues/33, this color scheme could be used as a fallback by other color schemes when the environment does not have enough colors. That is, the other color schemes might be structured as follows:
if <has GUI or at least 256 colors>
" Color scheme definitions
else " Fallback
let g:colors_fallback = 1
source $VIMRUNTIME/colors/none.vim
endif
The colors_fallback flag could be used by None to detect whether it's been selected by the user or invoked as a fallback, and act accordingly (e.g., not reset g:colors_name when used as a fallback).
Then, all other color schemes should only define GUI and xterm colors.
There's a caveat to the above: many (most?) Vim's color schemes use ANSI colors. While for new color schemes the approach I have mentioned is not an issue, it would break backward compatibility.
@lifepillar It's a catch-all solution for people working in busted environments that they don't have the privileges or the know-how to fix. It's overkill on purpose, as the only assumption is that foreground/background are legible.
The template is derived from one of my other themes, beware of the cruft : None.zip