bold is missing for TUI

[habamax]

Bold is set only for gui, at least for pablo.

We should check all others too.

https://github.com/vim/colorschemes/issues/170

[habamax]

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]

Bold is set only for gui, at least for pablo.

We should check all others too.

https://github.com/vim/colorschemes/issues/170

Note that some (old) terminals use bold to indicate a different color.

-- Two fish in a tank. One says to the other: "Do you know how to drive this thing?"

/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \\ /// \\ \\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

[habamax]

@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?

[romainl]

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.

[habamax]

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?

[romainl]

@habamax literally nothing beyond being aware of that when the question pops up.

[neutaaaaan]

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.

[romainl]

@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=256 fixes the bold issue.
• Maybe Vim should forcefully :set t_Co=256 for cmd.exe. It will probably break in older versions of cmd.exe. Do we care?

[habamax]

@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.

[chrisbra]

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: https://github.com/vim/vim/issues/9498

[habamax]

@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

[brammool]

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: https://github.com/vim/vim/issues/9498

We dropped the support for Windows 95/98/ME. Windows XP is the oldest that we keep working. Does the Windows XP console support 256 colors?

-- Facepalm reply #3: "I had a great time in Manhattan" "I thought you were going to New York?"

/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \\ /// \\ \\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

[romainl]

Does the Windows XP console support 256 colors?

I will tell you in a few minutes ;-)

[romainl]

@brammool No, The console doesn't really support 256 colors in XP:

[brammool]

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/

[habamax]

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

[brammool]

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

At some point it only supported 16 colors. I still am not sure how to detect whether more colors actually work.

This article suggests it was introduced in build 14931: https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/

Which was an "insiders build", thus not generally available.

-- ZOOT: I'm afraid our life must seem very dull and quiet compared to yours. We are but eightscore young blondes, all between sixteen and nineteen-and-a-half, cut off in this castle, with no one to protect us. Oooh. It is a lonely life ... bathing ... dressing ... undressing ... making exciting underwear.... "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \\ /// \\ \\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

[chrisbra]

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?

1) initially vim.exe --clean README.md 2) :set t_Co=256 3) :hi Normal ctermbg=black guibg=dark ctermfg=white guifg=white

Does that make sense?

[habamax]

@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)

[romainl]

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.

[brammool]

Have you tried the patch to use 256 colors in Windows if it should work? https://github.com/vim/vim/pull/10495

[habamax]

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)

[habamax]

https://github.com/vim/vim/pull/10563