-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overload Console.Write and Console.WriteLine to take ConsoleColor as a parameter #39746
Comments
Tagging subscribers to this area: @eiriktsarpalis |
@abhaycashikar thanks for the suggestion. Could you please edit your suggestion above to follow the format here: https://github.com/dotnet/runtime/issues/new?assignees=&labels=api-suggestion&template=02_api_proposal.md&title= Making it explicit and formatted like that will help us review it. |
Hi @danmosemsft, I apologize for not using that formatting initially! I've edited the issue to match it now, with the exception of the diff block in Proposed API (I thought it didn't really make sense since it would just be all additions). |
@abhaycashikar looks good...could you add that diff block although it's just an add? That helps the review process. |
Sure, no problem. |
If you have source code that calls this method, but compile it against a target framework that does not have the method, then overload resolution chooses |
I think the name of the string parameter should be |
Linking as related: #34742. There was a lot of discussion in the reviews of that API about color, and the consensus was that BCL should consider adding some |
According to PowerShell/PowerShell#13071 (comment), PowerShell has prototyped System.CommandLine.Rendering for colors. However, that package is still in prerelease, lacks documentation, and is far more complex than the API being proposed here. |
@abhaycashikar nit, the diff section would just look like + public static void WriteLine(string str, ConsoleColor foreground, ConsoleColor background) { throw null; } At this stage, we don't care about implementation. As other folks pointed out above, this is not as simple an addition as it may seem 😄 |
A developer writing Console.ForegroundColor = ConsoleColor.Blue;
Console.BackgroundColor = ConsoleColor.Black;
Console.WriteLine("Blue on black.");
Console.WriteLine(ConsoleColor.Red, ConsoleColor.Green, "This output is red on green.");
Console.WriteLine("Guess what this is!"); could expect that the third line is again blue on black. However, that is difficult or impossible to implement if |
I don't think it's worth the risk to add 16 color support to the Console api when we should be adding 16 million color support. @KalleOlaviNiemitalo is on the right track here, the Windows Console supports RGB colors now, and does not support controlling those colors through the Win32 API. There's no point trying to update System.Console. We just need to use VT based APIs through the |
That's a little harsh in my view. |
It would be useful if this API was integrated with the normal locking that writing to the console does. |
I was just going to file a similar proposal with almost identical motivation but found this one so I will add my thoughts to this discussion. First of all, I'd expect this API would not reset colors to default after writing but reset to previous: Console.ForegroundColor = ConsoleColor.Yellow;
Console.WriteLine(ConsoleColor.Red, ConsoleColor.Black, "Red on Black");
Console.WriteLine("Yellow on Black"); // Not White on Black or whatever the default combination is Second - I think that all the overloads of Write(ConsoleColor foregroundColor, ConsoleColor backgroundColor, int value);
WriteLine(ConsoleColor foregroundColor, ConsoleColor backgroundColor, string format, params object[] args); Imho foreground color is changed much more frequently than the background color, so it'd be nice to have overloads that change only the foreground color: Write(ConsoleColor foregroundColor, string value); For the two-color-parameters overloads, the colors may be made nullable so you can change only the non-null color. These may, however, only be added if the color-changing methods have names different to Console.ForegroundColor = ConsoleColor.Yellow;
Console.WriteLine(null, ConsoleColor.DarkBlue, "Yellow on Dark Blue"); Btw if this gets approved, I'm willing to implement it 😊 |
How would you implement that? The Windows console host does not support XTPUSHSGR and XTPOPSGR yet (microsoft/terminal#1796). |
ConsoleColor previousColor = Console.ForegroundColor;
Console.ForegroundColor = ConsoleColor.Red;
Console.Write("Red text");
Console.ForegroundColor = previousColor; |
That cannot restore the color properly if the previous color is not any of the 16 colors supported by the |
It could be a note in the documentation. I think that if users are using RGB colors, they'd not be using this method :D |
Agreed, if anything your typical console app does not use the same colors for entire lines, so arguably a |
(I was directed to repost this feature request here.)
Background and Motivation
I'm trying to create a user-friendly command-line application, and as such I wanted to color my output to the console. However, I found myself frequently writing code like this:
Proposed API
I thought it might be a lot easier for
Console
to have an overload onWrite
andWriteLine
that takes in twoConsoleColor
elements as arguments for theForegroundColor
andBackgroundColor
variables and abstracts this process away from the developer. This way, the process of setting theForegroundColor
andBackgroundColor
variables, writing to the console, and resetting the color can be written as one line in code. I think something like the below would work:+ public static void WriteLine(ConsoleColor foreground, ConsoleColor background, string value) { throw null; }
Usage Examples
would be equivalent to the code in the Background and Motivation section.
Alternative Designs
If overloading is not possible, additional methods like
WriteColor
andWriteLineColor
would still be very useful in my opinion.Risks
I'm not really sure if there are any risks that come with making this change. I don't think there would be because the functionality would just use the existing methods in
Console
and the existingConsoleColor
enum.The text was updated successfully, but these errors were encountered: