bold is missing for TUI
habamax opened this issue · 23 comments
Let it be open for awhile. I think I have fixed all "bold" issues for TUI, but might miss something.
All fixes were related to boldness of Syntax highlight groups.
@brammool There is another issue with bold (and this was the main reason we tried to avoid it even if it was present in legacy) -- default experience of vim on cmd.exe is ugly/unreadable for bold syntax elements.
By default vim in cmd.exe is set to t_Co=16 where bold looks like this, for example:
On the other hand if you set t_Co=256 everything is ok.
Would it be possible to have default t_Co=256 for vim in cmd.exe?
Assuming 256c in CMD.exe would probably be fine for most people… until someone tries it on Vista or something.
FWIW, in macOS's Terminal.app, there is an option for using bold fonts for, well, bold, and another option for using bright colors for bold so the result can be very wild compared to what is intended by the colorscheme author.
FWIW, in macOS's Terminal.app, there is an option for using bold fonts for, well, bold, and another option for using bright colors for bold so the result can be very wild compared to what is intended by the colorscheme author.
I don't think we could do anything about it, right?
Boring story time:
Back in the serial terminal days, bold meant bright, as in drive the electron beam a bit harder here. The characters produced were brighter and also a bit bolder because of surrounding phosphors being excited.
This is really not something that can be achieved on a modern display, hence (to my knowledge) most terminal emulators defaulting to the bright attribute using a bold typeface, and also potentially using brighter colors (which I believe are a mid 90s addition to make up for the absence of bold typefaces in some contexts). I seem to remember that generally speaking, with most terminal emulators I tried but didn't configure, I'd get both at the same time, and that's how I've set up every terminal emulator I've used ever since.
We're absolutely never going to get rid of the fact that some people have their terminal emulators configured to think that bold black should be ansi color 8 and thus grey, or that ansi color 8 is supposed to be bold. This behaviour is (in most contexts) wrong. Yet, it's too common to even consider changing.
Back to the subject at hand:
I'm confused, my understanding is that you guys had ripped bold out of all colorschemes because it wouldn't work properly in cmd.exe.
I didn't agree with the decision then (I'm all for lowest common denominators, but the one that motivated this decision is broken beyond belief), but as it didn't seem to concern potential future additions to the default colorschemes (forsake clearly broken environments for the benefit of basically everything else) I didn't put up much of a fight.
I'm not sure if you guys are thinking about bringing bold back or what.
@neutaaaaan thank you for that historical background.
As for what to do, we are facing a little conundrum, here.
- some remakes are obviously less useful with bold removed so it would seem to be a user-friendly move to bring back bold,
- Vim doesn't know how to do bold correctly in cmd.exe in its default configuration, which makes all coloschemes relying on bold unusable in that context.
So, either we remove bold and we annoy non-cmd.exe users or we bring it back and we annoy cmd.exe users.
Of note:
- Cmd.exe is recognised as 16c by default but doing
:set t_Co=256fixes the bold issue. - Maybe Vim should forcefully
:set t_Co=256for cmd.exe. It will probably break in older versions of cmd.exe. Do we care?
@chrisbra do you think t_Co=256 for windows cmd is a viable solution?
It would be nice to bring bolds back in a way they work in windows too.
I personally think so. Note Vim will currently use cmd.exe with 16 colors until the user has enabled and disabled termguicolors. After that, Vim will silently use 256 colors for cmd.exe already: vim/vim#9498
@romainl @neutaaaaan I guess we can assume, cmd.exe vim would have 256c by default in the future, thus we can/should provide bolds in remade colorschemes
Does the Windows XP console support 256 colors?
I will tell you in a few minutes ;-)
It seems that this article suggests that even Window 10 only has 16 console colors:
https://devblogs.microsoft.com/commandline/updating-the-windows-console-colors/
It seems that this article suggests that even Window 10 only has 16 console colors:
These are default first 16 colors that were slightly changed for win10.
cmd.exe support 16, 256 and termguicolors just fine.
It is just when in t_Co=16 it renders bold with different background
According to os_mswin32.c it was build 1703:
https://github.com/vim/vim/blob/78d52883e10d71f23ab72a3d8b9733b00da8c9ad/src/os_win32.c#L7760-L7764
so released about 5 years ago and I would think, that all windows users have that nowadays and we already have all the has_vtp_working() conditionals to check if this is available.
But regardless, I just tried the following, in a plain cmd.exe, that is capable of termguicolors. If I just run :set t_Co=256 it turns into a bright color background. and is hard to read. I have to ensure that Normal highlighting is defined, than it seems to work. Is that just me or is there something broken?
- initially
vim.exe --clean README.md
:set t_Co=256
:hi Normal ctermbg=black guibg=dark ctermfg=white guifg=white
Does that make sense?
@chrisbra the same. "Transparent" normal for cmd.exe in this case is weirdly incorrect. Works ok for remade legacies as they all have normal defined.
Looks like another obstacle to have 256c by default (unless it would be fixed ofc)
So, it looks like we are back to square one.
The situation:
- The Windows console advertises itself as 16c by default and/or Vim detects 16c by default.
- Vim can't do bold correctly in the Windows console in 16c.
- The Windows console has been 256c-ready for a while.
- Vim can do bold correctly in the Windows console in 256c.
- Vim is backward compatible to Windows XP.
- 256c was added to the Windows console long after XP.
- Vim's built-in colorschemes can't rely on bold in the Windows console.
Things we don't particularly want to do:
- Break compatibility with Windows XP.
- Distribute broken colorschemes to Windows users.
- Add too much complexity to the colorschemes themselves.
- Distribute platform-specific colorschemes.
Things we may be OK with:
- Changing whatever needs to be changed in Vim's core so that it can do bold correctly in the Windows console in 16c.
- Changing whatever needs to be changed in Vim's core so that it can decide whether or not to assume 256c in the Windows console.
Have you tried the patch to use 256 colors in Windows if it should work?
vim/vim#10495
Have you tried the patch to use 256 colors in Windows if it should work?
I can only test it once it is in nightly build (compiling things on windows is a pain in the back)