Removed bold atribute for terminals

[romainl]

Should fix https://github.com/vim/colorschemes/issues/151

[habamax]

peachpuff pmenu

[habamax]

underline (applied to cursorline) is a no-go too

[habamax]

Delek both in 16 and 256

[habamax]

elflord 256

elflord 16

[habamax]

industry both in 256 and 16

[habamax]

pablo

[habamax]

torte

[habamax]

zellner

[habamax]

Bolds are removed indeed.

Fixes needed are:

• Statuslines were dependent on bold attribute so now some of them are ^^^^^^^^^
• some Statuslines have no background
• peachpuff has unreadable selected pmenu
• probably some more

for the underline lets address it in another go/pr

[habamax]

cmd.exe does nothing with reverse so many statuslines are broken there

[romainl]

cmd.exe does nothing with reverse so many statuslines are broken there

Sigh

[habamax]

@romainl pls check my changes

I did check against xterm16 and cmd.exe but could miss here and there.

[habamax]

@romainl done

[habamax]

That 16c cmd.exe is an abomination (again reverse):

ok for 256c

[habamax]

If we want to support it we will have to add a conditional into _diff for win32 and t_Co.

[habamax]

Or just remove reverse and switch fg and bg manually

[romainl]

The observations below are valid for CMD.exe in Windows 10 version 1809 from fall 2018.

• &t_Co is set to 16 by default by Vim
• the bold, reverse, underline, and italic attributes are 100% unreliable in the default scenario
• cursorline can't be underline
• cursorline can have a regular ctermbg and ctermfg but a) the choice of colors is very limited in 16c, and b) the colors are user-editable anyway (but that is a global 16c issue that we can't get around)
• the console actually supports 256 colors
• &t_Co can be set to 256 in Vim in which case we get a mostly working colorscheme
• in 256c, underline et reverse work as expected so they seem to be safe
• in 256c, bold and italic don't do anything so it is best to not rely on them
• Vim is not good at inferring terminal capabilities so we can't rely on it for making the right decisions
• It might be possible to do some detection in vimscript, therefore in the colorscheme itself but that seems brittle and we don't really want more logic in there

What to do with 16c CMD.exe?

• Tone down 16c until it works in the worst 16c environment?
• Tell the user to do :set t_Co=256?
• Mention portability issues in the appropriate help sections like :help 'cursorline'?

[romainl]

@habamax in c50e5ef the templates are missing. Does that mean that you worked directly on the colorschemes?

[neutaaaaan]

Vim is not good at inferring terminal capabilities so we can't rely on it for making the right decisions

I'd try to get that fixed, or at least have the windows terminal and cmd.exe situation figured out.
Considering they're relatively different from the unix terminal ecosystem, they might be easier to autodetect. We could then try to automatically load more compatible versions of the colorschemes, and probably throw some kind of warning and user manual reference in the ModeMsg line, with potential modifications to be made to the user's .vimrc.

Considering that vim is exceedingly unlikely to ever be installed by default on a windows machine, this would be a much better solution to me than effectively kneecapping the default colorschemes in all possible 16c contexts.

Does _tcozero even survive being used in cmd.exe ?

[habamax]

@romainl no, I did everything using templates -- there should be _diff changed

[romainl]

Vim is not good at inferring terminal capabilities so we can't rely on it for making the right decisions

I'd try to get that fixed, or at least have the windows terminal and cmd.exe situation figured out. Considering they're relatively different from the unix terminal ecosystem, they might be easier to autodetect. We could then try to automatically load more compatible versions of the colorschemes, and probably throw some kind of warning and user manual reference in the ModeMsg line, with potential modifications to be made to the user's .vimrc.

Considering that vim is exceedingly unlikely to ever be installed by default on a windows machine, this would be a much better solution to me than effectively kneecapping the default colorschemes in all possible 16c contexts.

I agree on principle but it is something I, personally, am not equipped for. My opinion has been for a long time that the nasty colors/style/capabilities business should be fixed in Vim itself but, in the end, the work has to be done by someone and I don't have the expertise be that someone. So I don't feel comfortable taking a stand and saying "let's do it" because the "'s" means "us" and a) I will be of no help, and b) it will mean "do it". I don't like it at all.

Does _tcozero even survive being used in cmd.exe ?

Given the liberal use of stylistic attributes I doubt it.

[romainl]

@habamax sorry.

[habamax]

Does _tcozero even survive being used in cmd.exe ?

Probably not. Manual set t_Co=0 has no effect, it is being reset to 16.

[neutaaaaan]

@romainl I agree this has to be fixed upstream, I don't have the technical know-how either.

I'm against gimping colorschemes to work around well-documented, long-standing issues in vim itself. There's absolutely no point in building on top of broken foundations.

[habamax]

Most of the readability issues were solved in this PR.

Cursorline is what I don't know what to do with.

[habamax]

I would suggest to

• check what we have now, merge it, update vim/PR
• Do nothing with CursorLine as of now.

[romainl]

Properties of the Windows console before :set cursorline and after :set nocursorline:

Properties of the Windows Console after :set cursorline:

We can't do anything about it at our level so I think we will stop working on that topic for now (and open an issue against vim/vim).

[romainl]

So, leaving the cursorline issue out of the question for now…

• are the remakes usable in xterm-like terminal emulators with the default palette?
• are the remakes usable in the Windows console with the default palette?

[habamax]

• are the remakes usable in xterm-like terminal emulators with the default palette?

Yes

• are the remakes usable in the Windows console with the default palette?

Yes

But I could miss smth

[romainl]

I spotted a few instances where the contrast between StatusLineNC and StatusLine was not good enough. There is also at least one unreadable wildmenu. I'm on it.

[romainl]

@habamax what do you think?

[habamax]

@romainl looks good, checked with gui and cmd.exe (16c)

[romainl]

OK, let's go.