Fixes #4191 Make v2 true color on by default (i.e. opt out)

[tznind]

Fixes

• Fixes CJK Characters doesn't render correctly on Alacritty (v2_develop) #4191
• Fixes Windows drivers are forcing 16 color mode by default on some terminals #4188

Proposed Changes/Todos

We now assume SupportsTrueColor is true unless user explicitly sets false themselves.

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[BDisp]

Still not the best option. This is from your branch using Alacritty.

[tznind]

That's right, I fixed this in #4193 but that makes worse for cmd.exe

[BDisp]

In cmd.exe or conhost.exe, when virtual terminal is disabled you need avoid sending escape sequence at all.

[tznind]

There is no cross terminal solution for wide characters using the kernel32 api WriteConsoleOutputW (the one we are using for 16 colors).

I created this repro:
https://github.com/tznind/16-color-console-tests

The test cases are as follows

Test Case	Written
' '	['你', ' ', 'c','d']
'\0'	['你', '\0', 'c','d']
<none>	['你', 'c','d']

Here is a comparison of various terminals. Notice that there is no column that works for all 3.

Terminal	' '	'\0'	<none>
Alacritty
Windows Terminal
cmd.exe (NSimSun font)

[BDisp]

Alacritty is who rendering correctly. It's impossible to use WriteConsoleOutputW to render all surrogate pairs codepoints correctly, because, some has a width of 1 and others a width of 2. For wide char in the bmp range From: U+0000. To: U+FFFF, it handle more or less, but not for non-bmp (surrogate pairs), which need other library to output correctly.

[tznind]

Ok seems the correct way to handle this is to switch to the newer APIs (WriteConsoleW and SetConsoleTextAttribute (for 16 color)

Test Case	Written
' '	['你', ' ', 'c','d']
'\0'	['你', '\0', 'c','d']
<none>	['你', 'c','d']
modern	Uses WriteConsoleW and SetConsoleTextAttribute instead (write as string)

Results:

Terminal	' '	'\0'	<none>	modern
Alacritty
Windows Terminal
cmd.exe (NSimSun font)

[tznind]

Based on the above I have started a rewrite of 16 color mode in WindowsOutput (v2).

Here is WIP:
#4193

I think I can declutter some of this class while I am at it.

[tig]

A thot I had long ago was we'd eventually have 3 drivers:

• ansi
• net
• win (legacy)

What are your thoughts on moving in this direction?

[tznind]

What's the difference between ansi and net? Both use pure escape sequences I think

…

On Mon, 21 Jul 2025, 13:42 Tig, ***@***.***> wrote: *tig* left a comment (gui-cs/Terminal.Gui#4195) <#4195 (comment)> A thot I had long ago was we'd eventually have 3 drivers: - ansi - net - win (legacy) What are your thoughts on moving in this direction? — Reply to this email directly, view it on GitHub <#4195 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHO3C5CBYNA2GKDQ733PAR33JTN4NAVCNFSM6AAAAACBWOWA7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJWGYYDEMZYHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tig]

What's the difference between ansi and net?

Both use pure escape sequences I think

On Mon, 21 Jul 2025, 13:42 Tig, @.***> wrote:

tig left a comment (#4195)

#4195 (comment)

A thot I had long ago was we'd eventually have 3 drivers:

• ansi

• net

• win (legacy)

What are your thoughts on moving in this direction?

—

Reply to this email directly, view it on GitHub

#4195 (comment),

or unsubscribe

https://github.com/notifications/unsubscribe-auth/AHO3C5CBYNA2GKDQ733PAR33JTN4NAVCNFSM6AAAAACBWOWA7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJWGYYDEMZYHA

.

You are receiving this because you authored the thread.Message ID:

@.***>

Good question. I haven't looked at your code closely in a while. If it is in fact how we do "pure ansi that works xplat" then it fits.

Pure ansi, to me, means the ONLY ansi sequences emitted are sequences WE emit btw.

If v2net fits this, then

• It should be the default
• It should have a name that indicates its pure ansi
• v2win should either go away or be named something that indicates "for stupid legacy Windows legacy cases where users can only use conhost"

Right?

[tznind]

Yes v2net works almost exclusively with standard csharp dotnet methods and escape sequences.

There is some dll import stuff in NetWinVTConsole that is used in windows to turn on support for these sequences

Modern Windows 10+ consoles can support ANSI, but you must explicitly enable it using:
SetConsoleMode(handle, mode | ENABLE_VIRTUAL_TERMINAL_PROCESSING);

• All input mouse events come in as escape sequences
• Many key combinations (e.g. arrow keys, Function keys) also come in as escape sequences

Input is read as ConsoleKeyInfo using Console.ReadKey (true) (core dotnet method).

Input sequences are detected and processed by AnsiResponseParser (including AnsiMouseParser and AnsiKeyboardParser).

It is called 'net' because it uses only core dotnet methods.

Output primarily uses escape sequences for color, style etc. It does mix in some dotnet calls e.g. Console.SetCursorPosition and of course Console.Out.Write but no dll imports.

I agree v2net should be default - It does seem there is anecdotal evidence of people having issues with it on windows. This is probably because of the wide range of versions of terminals out there fore windows, some with known bugs.

v2win has 2 modes

• 16 color mode (which really is just - don't send terminal sequences)
• 'Normal' mode. Which is primarily terminal sequences but also some native methods like buffer switching etc.

[tig]

@tznind super important that we view all this through 3 lenses:

1. Output (which essentially boils down to emitting ANSI sequences)
2. Mouse Input
3. Keyboard Input

The discussion above is mostly about 1.

The dotnet console API is VERY broken relative to 3 on Windows (but, oddly, not Linux). See dotnet/runtime#96490

Until that issue is fixed, I'm afraid v2net will never work correctly for keyboard input. But there may be a way around it...