I have to admit that I'm not very familiar with the technicalities of terminals. If I understand you correctly then the way color is set on a terminal depends on the terminal itself and not the platform? I assumed that it was a platform specific detail, and as long as you knew that you were compiling for Linux for example, then you would know how the implementation should behave in order to work on Linux. But if it's left up to each individual terminal how color should be set then I agree that colored printing sounds difficult to implement in the standard library and might just be left to 3rd-party libraries.
But if it's up to every individual terminal how it should be implemented, then how does C# manage to make it work?
Sorry for asking two questions in one response.

________________________________
Fra: Tiago Freire <tmiguelf_at_[hidden]>
Sendt: mandag 20. mai 2024 20:47
Til: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Jan Schultke <janschultke_at_[hidden]>
Kopi: Henrik Nyhammer <hsn95_at_[hidden]>
Emne: RE: [std-proposals] Colored printing for std::print and std::println


I agree with Jan on this one.

Although there’s a quasi-standard for virtual terminal sequences, it is still up to the terminal implementer to adopt it.

Some terminals don’t adopt it, other terminals adopt a different method to do the exact same thing (and which do you adopt?).



Not everything that you can do with C++ needs to be in the C++ standard.

VT sequences are readily available and relatively easy to integrate, it is better to be left as a third-party library.

There’s no need to discuss about which terminal to support, how to actually implement it, and how would you make it work in a coherent manner given the terminal zoo, when you can just make up your own library that works for you and use it.



I feel that there is a general will to modernize the way terminals work (and there are people actively working on it trying to solve certain problems), but I don’t think there will be much that the C++ standard will have a say in.



Some parts of C++ may have features that assume the existence of a terminal, but how a terminal behaves has nothing to do with the programming language, but with the specific implementation of the terminal.







From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Henrik Nyhammer via Std-Proposals
Sent: Monday, May 20, 2024 19:22
To: Jan Schultke <janschultke_at_[hidden]>
Cc: Henrik Nyhammer <hsn95_at_[hidden]>; std-proposals_at_[hidden]
Subject: Re: [std-proposals] Colored printing for std::print and std::println



To clearify, I mean that it would be nice to add an API based on the one from fmt, while leaving the implementation of it to the C++ implementors. That way we could have an API that fits nicely together with std::println, but without having to resort to something like ANSI escape sequences on platforms where it doesn't make sense to do so. I think that if we added something like this it would be a huge boost to what you can achieve with the standard library alone. And without it you're left with resorting to 3rd-parties as soon as you want to do something slightly more fancy in your console application, which is a small hassle in itself, and the 3rd-party library may be implemented in a way that does not work well with a lot of consoles out there anyway, like using ANSI escape sequences.

Also, other languages like C# comes with this feature out-of-the-box, so why shouldn't C++ do so?



20. mai 2024 08:09 skrev Jan Schultke <janschultke_at_[hidden]<mailto:janschultke_at_[hidden]>>:

Colored printing is generally useful, but I think it's better done
using third-party libraries.

The link you've posted relies on ANSI escape sequences, and not every
terminal emulator supports them. Older versions of cmd.exe didn't
allow for this, for example. I'm also not sure how consistent various
terminal emulators are in implementing the various ANSI escape codes.
ANSI sequences also aren't something nice that can be abstracted from
easily, like RGB colors. They are made of various palettes and it all
feels a bit arbitrary.

All you need to get some basic ANSI features is to include some header
with a bunch of "inline constexpr string_view" constants for various
ANSI codes, so it's also not like this *needs* to be in the standard
library for a viable implementation. It's quite trivial.