Developers using Console can employ VT/ANSI APIs (eg to use embedded color codes)

[maryamariyan]

Usage in Microsoft.Extensions.Logging.Console

Console Formatters introduced in .NET 5.0 allow for the built-in SimpleConsoleFormatter to embed color codes to each log message. But this implementation required knowledge about hardcoding a mapping between VT100 color codes and different background/foreground color changes.

Instead of typing colors to the formatter, we should decouple this by exposing a generic VT100 builder for colors (maybe even a parser) into System.Console. This way, we can simplify the architecture in Microsoft.Extensions.Logging.Console by making ConsoleFormatters's job purely about building up string of log messages structured in a specific format when having colors involved.

• AnsiParser.cs#L135-L172

Usage in System.CommandLine.Rendering

• System.CommandLine.Rendering/Ansi.cs shows similar logic being duplicated in dotnet/command-line-api as well.

cc: @eerhardt

Tagging subscribers to this area: @eiriktsarpalis, @jeffhandley
See info in area-owners.md if you want to be subscribed.

---

Issue meta data

Issue content:	### Usage in Microsoft.Extensions.Logging.Console Console Formatters introduced in .NET 5.0 allow for the built-in SimpleConsoleFormatter to embed color codes to each log message. But this implementation required knowledge about hardcoding a mapping between VT100 color codes and different background/foreground color changes. Instead of typing colors to the formatter, we should decouple this by exposing a generic VT100 builder for colors (maybe even a parser) into System.Console. This way, we can simplify the architecture in Microsoft.Extensions.Logging.Console by making ConsoleFormatters's job purely about building up string of log messages structured in a specific format when having colors involved. AnsiParser.cs#L135-L172 Usage in System.CommandLine.Rendering System.CommandLine.Rendering/Ansi.cs shows similar logic being duplicated in dotnet/command-line-api as well.
Issue author:	maryamariyan
Assignees:	-
Milestone:	[object Object]

[eerhardt]

System.CommandLine.Rendering/Ansi.cs shows similar logic being duplicated in dotnet/command-line-api as well.

Another useful part of System.CommandLine.Rendering that we may want to pull into the BCL is the ConsoleFormatInfo class. This allows for ANSI control codes to be included or omitted dynamically depending on the current environment, or explicitly configured by a caller. (The design follows the same design as formatting a number or a date in the rest of .NET.)
See dotnet/command-line-api#966 for more info.

[SteveL-MSFT]

I think the biggest help to PowerShell is a .NET API that returns the plain text version of a string (removing all ANSI decoration).

[iSazonov]

If we look not PowerShell itself but PowerShell module PSReadline - I believe we can find some other methods which could be great candidates for System.Console VT/ANSI APIs.
I hope @daxian-dbw could add more info.

[iSazonov]

In short:

1. Transparent support more terminals by utilizing TermInfo (on Windows too). This allows an application turn on/off coloring (and other feature) on the fly and to work on any terminal without recompile.
2. Support modern coloring 24/32bits Discussion: PowerShell needs to support 24bit color. Where? How? PowerShell/PowerShell#2381
3. API for calculating string length with and without escape codes.
4. API for calculating string length for cells to support fullwidth forms. PSReadline workaround
5. Maybe a rendering engine based on TermInfo entities. This could significantly reduce allocations in custom code, add formattings in resource strings and so on.
6. API for managing cursor position, getting info about a terminal sizing and resizing.
7. Supporting alternative terminal buffers.
8. Supporting scrolling
9. Supporting clearing screen and whole buffer.
10. Full featured cross-platform line editor. Enhance Console.ReadLine() to return at Tab #800

/cc @DHowett