Closed habamax closed 3 years ago
@romainl fyi
I have changed "ugly" red of PreProc to red-brownish color #d7875f
Some comments.
This file does not define a color scheme if &t_Co < 256
with set notermguicolors
(for example in cmd.exe on Windows).
The remaining comments apply to gVim.
The Cursor
and Search
highlight groups are pretty similar. For example, with /hi
and the cursor located on the first "hi":
Cursor
and DiffAdd
have the same guibg
. In the image below, the cursor is on the extra line in the right-hand buffer and is not visible.
CursorLine
on DiffChange
makes the text difficult to read:
Also with CursorLine
on DiffAdd
:
Thanks, @gdupras
t_co<256
is out of question as it is not the goal for me.
If anybody else would like to make it for 16 colors -- I would like to see the results :)
As for the rest, I will check it when there is a time window.
(for example in cmd.exe on Windows)
cmd.exe supports 256 colors:
You're right but by default it's 16 colors and colorschemes should work out of the box. Sorry, I'm just nitpicking :)
You're right but by default it's 16 colors and colorschemes should work out of the box. Sorry, I'm just nitpicking :)
Yeah, but if you know reliable way to make it work for 16 "random" colors -- tell us :)
I mean, I don't think there would be anything better than a fallback to default colors in case of t_Co=16
.
@gdupras "works in 16c" must be defined precisely.
If it means "is guaranteed to look like the screenshot no matter what", then "works in 16c" is unattainable.
If it means "is guaranteed to be usable no matter what", then "works in 16c" is very difficult and limited.
If it means "we tried our best to make it usable in 16c but guaranteeing anything is impossible under those conditions so you will be better off with a 256c $TERM
", then "works in 16c" is doable.
That, and some of the OG colorschemes are very GUI-oriented anyway, in which case the 16c experience is pretty close to default
.
If it means "we tried our best to make it usable in 16c but guaranteeing anything is impossible under those conditions so you will be better off with a 256c $TERM", then "works in 16c" is doable.
This is what I had in mind. Yes, what can be done with 16c is pretty limited. Ideally it should have the same general feel as the 256c version. For example blue.vim should have a lot of, well, blue. The new blue.vim successfully achieves this.
I think at the very least it should look different than the default. The old slate.vim did so I would consider the lack of 16c support a regression. I realize that this is a work in progress and I don't blame anyone for not wanting to work with such a limited palette. I'm merely reporting what I've noticed after a quick test drive.
Gosh, I hate diffs in vim
They don't have to be horrid :)
I wonder… would it make sense to come up with a single diff colorscheme that we could use across all colorschemes?
I wonder… would it make sense to come up with a single diff colorscheme that we could use across all colorschemes?
If we go this route, it should be 2 at least, for lighter and darker backgrounds
How about this for slate:
It's OK, I guess. Picking diff colors outside of the main palette seems like a sensible move if we want *fg=NONE.
Damn, cterm bg wasn't amended for the dark blue, moment...
Relates #11