On Mon, May 20, 2024 at 7:16 PM Henrik Nyhammer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

I assume that on Windows, applications can just hardcode whatever they need
to do for `cmd.exe`.

On Unix, there's an environment variable called `TERM` that is supposed to
be set by the terminal emulator process, or, in the case of a hardware
terminal, `getty` or its equivalent, or in the case of a built-in console,
perhaps by `init`. The value of $TERM is looked up in the locally installed
"terminfo database", which for each kind of terminal known to the system
contains that terminal's list of "terminal capabilities", which includes
the specification of how to spell particular control sequences such as
those used to set the foreground and background colour of text. The
cross-platform interface to the terminfo database is `curses.h`. Though I
believe most kinds of Unix terminals that you're likely to encounter
nowadays share most of their common escape sequences with the `xterm`
terminal type, so if you just assume the terminal is `xterm` and hard-code
the values correspondingly, it'll work most of the time.


>
> ------------------------------
> *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]
> <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.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*