Thread: color by default
With the attached patch, I propose to enable the colored output by default in PG13. For those who don't like color output, I also add support for the environment variable NO_COLOR, which is an emerging standard for turning off color across different software packages (https://no-color.org/). Of course, you can also continue to use the PG_COLOR variable. I have looked around how other packages do the automatic color detection. It's usually a combination of mysterious termcap stuff and slightly less mysterious matching of the TERM variable against a list of known terminal types. I figured we can skip the termcap stuff and still get really good coverage in practice, so that's what I did. I have also added a documentation appendix to explain all of this. (Perhaps we should now remove the repetitive mention of the PG_COLOR variable in each man page, but I haven't done that in this patch.) I'm aware of the pending patch to improve color support on Windows. I'll check that one out as well, but it appears to be orthogonal to this one. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Tue, Dec 31, 2019 at 11:40 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
I'm aware of the pending patch to improve color support on Windows.
I'll check that one out as well, but it appears to be orthogonal to this
one.
Actually I think it would be better to rebase that patch on top of this, as the Windows function enable_vt_mode() incorporates the logic of both isatty() and terminal_supports_color() by enabling CMDs support of VT100 escape codes.
Regards,
Juan José Santamaría Flecha
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
regards, tom lane
On Tue, Dec 31, 2019 at 7:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
+1
regards, tom lane
> On 31 Dec 2019, at 14:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> With the attached patch, I propose to enable the colored output by >> default in PG13. > > FWIW, I shall be setting NO_COLOR permanently if this gets committed. Me too. > I may well be in the minority, but I think some kind of straw poll > might be advisable, rather than doing this just because. +1 cheers ./daniel
På tirsdag 31. desember 2019 kl. 14:35:39, skrev Tom Lane <tgl@sss.pgh.pa.us>:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
It's easier to spot errors/warnings when they are colored/emphasized imo. Much like colored output from grep/diff; We humans have colored vision for a reason.
--
Andreas Joseph Krogh
Andreas Joseph Krogh
On 2019-Dec-31, Andreas Joseph Krogh wrote: > It's easier to spot errors/warnings when they are colored/emphasized imo. Much > like colored output from grep/diff; We humans have colored vision for a reason. I do use color output (and find it useful), for that reason. I'm not sure that the documentation addition properly describes the logic to be used; if it does, I'm not sure that the logic is really what we want. Is the logic in the docs supposed to be "last rule that matches wins" or "first rule that matches wins"? I think that should be explicit. Do we want to have NO_COLORS override the TERM heuristics? (I'm pretty sure we do.) OTOH we also want PG_COLORS to override NO_COLORS. Per https://no-colors.org (thanks for the link) it seems pretty clear that people who don't want colors should be already setting NO_COLORS, and everyone would be happy. It's not just PG programs that are colorizing stuff. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 31/12/19 14:35, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> With the attached patch, I propose to enable the colored output by >> default in PG13. > FWIW, I shall be setting NO_COLOR permanently if this gets committed. > I wonder how many people there are who actually *like* colored output? > I find it to be invariably less readable than plain B&W text. > > I may well be in the minority, but I think some kind of straw poll > might be advisable, rather than doing this just because. +1 ...and Happy New Year! / J.L.
On 01/01/2020 02:35, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> With the attached patch, I propose to enable the colored output by >> default in PG13. > FWIW, I shall be setting NO_COLOR permanently if this gets committed. > I wonder how many people there are who actually *like* colored output? > I find it to be invariably less readable than plain B&W text. > > I may well be in the minority, but I think some kind of straw poll > might be advisable, rather than doing this just because. > > regards, tom lane > > I find coloured output very difficult to read, as the colours seem to be chosen on the basis everyone uses white as the background colour for terminals -- whereas I use black, as do a lot of other people. Cheers, Gavin
On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower <GavinFlower@archidevsys.co.nz> wrote: > I find coloured output very difficult to read, as the colours seem to be > chosen on the basis everyone uses white as the background colour for > terminals -- whereas I use black, as do a lot of other people. I don't like colored output either. (It is, however, probably not a surprise to anyone that I am old-school in many regards, so how much my opinion ought to count is debatable. I still use \pset linestyle old-ascii when I remember to set it, use vi to edit, with hjkl rather than arrow keys, and almost always prefer a CLI to a GUI when I have the option. I have conceded the utility of indoor heat and plumbing, though, so maybe there's hope for me yet.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
I find color massively useful for grep and its variants, where the hit can show up anywhere on the line. It was also kind of useful for git, especially "git grep", but on my current system git's colorizing seems hopelessly borked, so I had to turn it off.
But I turned PG_COLOR on and played with many commands, and must say I don't really see much of a point. When most of these command fail, they only generate a few lines of output, and it isn't hard to spot the error message. When pg_restore goes wrong, you get a lot of messages but colorizing them isn't really helpful. I don't need 'error' to show up in red in order to know that I have a lot of errors, especially since the lines which do report errors always have 'error' as the 2nd word on the line, where it isn't hard to spot. If it could distinguish the important errors from unimportant errors, that would be more helpful. But if it could reliably do that, why print the unimportant ones at all?
It doesn't seem like this is useful enough to have it on by default, and without it being on by default there is no point in having NO_COLOR to turn if off. There is something to be said for going with the flow, but the "emerging standard" seems like it has quite a bit further to emerge before I think that would be an important reason.
Cheers,
Jeff
On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote: > On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower > <GavinFlower@archidevsys.co.nz> wrote: >> I find coloured output very difficult to read, as the colours seem to be >> chosen on the basis everyone uses white as the background colour for >> terminals -- whereas I use black, as do a lot of other people. > > I don't like colored output either. I don't like colored output either. However there is an easy way to disable that so applying this patch does not change things IMO as anybody unhappy with colors can just disable it with a one-liner in a bashrc or such. -- Michael
Attachment
On 06/01/2020 18:38, Michael Paquier wrote: > On Fri, Jan 03, 2020 at 01:10:30PM -0500, Robert Haas wrote: >> On Thu, Jan 2, 2020 at 6:38 PM Gavin Flower >> <GavinFlower@archidevsys.co.nz> wrote: >>> I find coloured output very difficult to read, as the colours seem to be >>> chosen on the basis everyone uses white as the background colour for >>> terminals -- whereas I use black, as do a lot of other people. >> I don't like colored output either. > I don't like colored output either. However there is an easy way to > disable that so applying this patch does not change things IMO as > anybody unhappy with colors can just disable it with a one-liner in > a bashrc or such. > -- > Michael That's kind of like using a sledgehammer to crack a nut. The colour in grep output is often useful. I'd like to control it per application. Cheers, Gavin
The patch to improve color support on Windows has been commited [1], and I would like to share some of the discussion there that might affect this patch.
- The documentation/comments could make a better job of explaining the case of PG_COLOR equals 'always', explicitly saying that no checks are done about the output channel.
Aside from the decision about what the default coloring behaviour should be, there are parts of this patch that could be applied independently, as an improvement on the current state.
- The new function terminal_supports_color() should also apply when PG_COLOR is 'auto', to minimize the chances of seeing escape characters in the user terminal.
- The new entry in the documentation, specially as the PG_COLORS parameter seems to be currently undocumented. The programs that can use PG_COLOR would benefit from getting a link to it.
[1] https://www.postgresql.org/message-id/20200302064842.GE32059%40paquier.xyz
- The documentation/comments could make a better job of explaining the case of PG_COLOR equals 'always', explicitly saying that no checks are done about the output channel.
Aside from the decision about what the default coloring behaviour should be, there are parts of this patch that could be applied independently, as an improvement on the current state.
- The new function terminal_supports_color() should also apply when PG_COLOR is 'auto', to minimize the chances of seeing escape characters in the user terminal.
- The new entry in the documentation, specially as the PG_COLORS parameter seems to be currently undocumented. The programs that can use PG_COLOR would benefit from getting a link to it.
[1] https://www.postgresql.org/message-id/20200302064842.GE32059%40paquier.xyz
Regards,
Juan José Santamaría Flecha
On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote: > - The new entry in the documentation, specially as the PG_COLORS parameter > seems to be currently undocumented. The programs that can use PG_COLOR > would benefit from getting a link to it. The actual problem here is that we don't have an actual centralized place where we could put that stuff. And anything able to use this option is basically anything using src/common/logging.c. Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we have no actual example of how to use it, and the original thread has zero reference to it: https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com And in fact, it took me a while to figure out that using it is a mix of three keywords ("error", "warning" or "locus") separated by colons which need to have an equal sign to the color defined. Here is for example how to make the locus show up in yellow with errors in blue: export PG_COLORS='error=01;34:locus=01;33' Having to dig into the code to find out that stuff is not a good user experience. And I found out about that only because I worked on a patch touching this area yesterday. -- Michael
Attachment
On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote: > On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote: > > - The new entry in the documentation, specially as the PG_COLORS parameter > > seems to be currently undocumented. The programs that can use PG_COLOR > > would benefit from getting a link to it. > > The actual problem here is that we don't have an actual centralized > place where we could put that stuff. And anything able to use this > option is basically anything using src/common/logging.c. > > Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we > have no actual example of how to use it, and the original thread has > zero reference to it: > https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com > > And in fact, it took me a while to figure out that using it is a mix > of three keywords ("error", "warning" or "locus") separated by colons > which need to have an equal sign to the color defined. Here is for > example how to make the locus show up in yellow with errors in blue: > export PG_COLORS='error=01;34:locus=01;33' > > Having to dig into the code to find out that stuff is not a good user > experience. And I found out about that only because I worked on a > patch touching this area yesterday. I can confirm there is still no mention of PG_COLORS in our documentation. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Thu, Mar 19, 2020 at 10:15:57PM -0400, Bruce Momjian wrote: > On Tue, Mar 3, 2020 at 02:31:01PM +0900, Michael Paquier wrote: > > On Mon, Mar 02, 2020 at 01:00:44PM +0100, Juan José Santamaría Flecha wrote: > > > - The new entry in the documentation, specially as the PG_COLORS parameter > > > seems to be currently undocumented. The programs that can use PG_COLOR > > > would benefit from getting a link to it. > > > > The actual problem here is that we don't have an actual centralized > > place where we could put that stuff. And anything able to use this > > option is basically anything using src/common/logging.c. > > > > Regarding PG_COLORS, the commit message of cc8d415 mentions it, but we > > have no actual example of how to use it, and the original thread has > > zero reference to it: > > https://www.postgresql.org/message-id/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com > > > > And in fact, it took me a while to figure out that using it is a mix > > of three keywords ("error", "warning" or "locus") separated by colons > > which need to have an equal sign to the color defined. Here is for > > example how to make the locus show up in yellow with errors in blue: > > export PG_COLORS='error=01;34:locus=01;33' > > > > Having to dig into the code to find out that stuff is not a good user > > experience. And I found out about that only because I worked on a > > patch touching this area yesterday. > > I can confirm there is still no mention of PG_COLORS in our > documentation. My mistake, PG_COLOR (not PG_COLORS) is documented properly. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian <bruce@momjian.us> writes:
>> I can confirm there is still no mention of PG_COLORS in our
>> documentation.
> My mistake, PG_COLOR (not PG_COLORS) is documented properly.
Yeah, but the point is precisely that pg_logging_init()
also responds to PG_COLORS, which is not documented anywhere.
regards, tom lane
On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > >> I can confirm there is still no mention of PG_COLORS in our > >> documentation. > > > My mistake, PG_COLOR (not PG_COLORS) is documented properly. > > Yeah, but the point is precisely that pg_logging_init() > also responds to PG_COLORS, which is not documented anywhere. Oh, I thought it was a typo. OK, so it still an open item. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.
Same.
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.
+1 on no color by default.
--
Jonah H. Harris
On Sat, 21 Mar 2020 at 00:25, Jonah H. Harris <jonah.harris@gmail.com> wrote:
On Tue, Dec 31, 2019 at 8:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> With the attached patch, I propose to enable the colored output by
> default in PG13.
FWIW, I shall be setting NO_COLOR permanently if this gets committed.
I wonder how many people there are who actually *like* colored output?
I find it to be invariably less readable than plain B&W text.Same.
For me it depends on what the colour is doing. I was very pleased when I first saw coloured output from ls, which if I remember correctly repeats the information provided by -F but more prominently. Similarly, I appreciate diff output that highlights the differences. At the same time I can appreciate a preference for "just plain text please".
I may well be in the minority, but I think some kind of straw poll
might be advisable, rather than doing this just because.+1 on no color by default.
Given that there is apparently a standard NO_COLOR environment variable which can be set, I think it's reasonable to default to gentle use of colour, but turn it off if the standard variable is set. Somebody who wants no color will probably already have the variable set, so in effect for the people who want it that way no colour would already be the default (not the default default, but the de facto default).
On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote: > On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote: >> Yeah, but the point is precisely that pg_logging_init() >> also responds to PG_COLORS, which is not documented anywhere. > > Oh, I thought it was a typo. OK, so it still an open item. Yes, I really think that we should have a new section in the docs for that with more meaningful examples rather than copy-paste that stuff across more pages of the docs. Note that 5aaa584 has plugged all the holes related to PG_COLOR I could find, and that pg_ctl and pg_upgrade initialize logging with pg_logging_init() but these two cannot use coloring because they have their own idea of what logging should be. -- Michael
Attachment
On 2020-03-23 06:04, Michael Paquier wrote: > On Fri, Mar 20, 2020 at 11:22:07PM -0400, Bruce Momjian wrote: >> On Fri, Mar 20, 2020 at 11:15:07PM -0400, Tom Lane wrote: >>> Yeah, but the point is precisely that pg_logging_init() >>> also responds to PG_COLORS, which is not documented anywhere. >> >> Oh, I thought it was a typo. OK, so it still an open item. > > Yes, I really think that we should have a new section in the docs for > that with more meaningful examples rather than copy-paste that stuff > across more pages of the docs. Note that 5aaa584 has plugged all the > holes related to PG_COLOR I could find, and that pg_ctl and pg_upgrade > initialize logging with pg_logging_init() but these two cannot use > coloring because they have their own idea of what logging should be. I'm giving up on making color the default, since there is clearly no consensus. Attached is the documentation patch reworked. Should we delete all the repetitive mentions on the man pages? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Mon, Mar 23, 2020 at 9:32 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
I'm giving up on making color the default, since there is clearly no
consensus.
Attached is the documentation patch reworked.
I think there is also some value in adding the functionality proposed in terminal_supports_color().
Regards,
Juan José Santamaría Flecha
On Mon, Mar 23, 2020 at 09:32:08AM +0100, Peter Eisentraut wrote: > Attached is the documentation patch reworked. Thanks! > Should we delete all the repetitive mentions on the man pages? I am not sure that deleting all the mentions would be a good idea, as we'd lose track of which tool supports coloring or not, and that could confuse users. What about switching the existing paragraph to a simple sentence with a link to the new appendix you are adding? Say: "pg_foo supports <place_your_link_here>colorized output</>". > + <para> > + The actual colors to be used are configured using the environment variable > + <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm> > + (note plural). The value is a colon-separated list of > + <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal> > + pairs. The keys specify what the color is to be used for. The values are > + SGR (Select Graphic Rendition) specifications, which are interpreted by the > + terminal. > + </para> A reference to SGR to understand better what's the list of values supported would be nice? > + <para> > + The default value is <literal>error=01;31:warning=01;35:locus=01</literal>. > + </para> Could it be possible to have more details about what those three fields map to? -- Michael
Attachment
On 2020-03-26 07:36, Michael Paquier wrote: > I am not sure that deleting all the mentions would be a good idea, as > we'd lose track of which tool supports coloring or not, and that could > confuse users. What about switching the existing paragraph to a > simple sentence with a link to the new appendix you are adding? Say: > "pg_foo supports <place_your_link_here>colorized output</>". I didn't do this because it would create additional complications in the man pages. But there is now an index entry, so it's possible to find more information. >> + <para> >> + The actual colors to be used are configured using the environment variable >> + <envar>PG_COLORS</envar><indexterm><primary>PG_COLORS</primary></indexterm> >> + (note plural). The value is a colon-separated list of >> + <literal><replaceable>key</replaceable>=<replaceable>value</replaceable></literal> >> + pairs. The keys specify what the color is to be used for. The values are >> + SGR (Select Graphic Rendition) specifications, which are interpreted by the >> + terminal. >> + </para> > > A reference to SGR to understand better what's the list of values > supported would be nice? I'm not sure how to do that. The full list of possible values is huge, and exactly what is supported depends on the terminal. >> + <para> >> + The default value is <literal>error=01;31:warning=01;35:locus=01</literal>. >> + </para> > > Could it be possible to have more details about what those three > fields map to? I have added information about that and explained the example values. I think if you search for "Select Graphic Rendition" and look for the example values, you can make sense of this. Committed with those changes. This closes the commit fest item. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-03-24 15:34, Juan José Santamaría Flecha wrote: > I think there is also some value in adding the functionality proposed in > terminal_supports_color(). What do you want to do with that functionality? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 29, 2020 at 11:56 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 2020-03-24 15:34, Juan José Santamaría Flecha wrote:
> I think there is also some value in adding the functionality proposed in
> terminal_supports_color().
What do you want to do with that functionality?
Add it to the tests done when PG_COLOR is "auto".
Regards
On Sun, Mar 29, 2020 at 02:55:37PM +0200, Juan José Santamaría Flecha wrote: > Add it to the tests done when PG_COLOR is "auto". FWIW, I am not sure that it is a good idea to stick into the code knowledge inherent to TERM. That would likely rot depending on how terminals evolve in the future, and it is easy to test if a terminal supports color or not but just switching PG_COLOR in a given environment and look at the error message produced by anything able to support coloring. -- Michael
Attachment
On Sun, Mar 29, 2020 at 11:56:15AM +0200, Peter Eisentraut wrote: > I didn't do this because it would create additional complications in the man > pages. But there is now an index entry, so it's possible to find more > information. Cannot you add a link to the page for color support in each one of them? That seems more user-friendly to me. > I'm not sure how to do that. The full list of possible values is huge, and > exactly what is supported depends on the terminal. An idea is to add a reference to SGR parameters directly from wikipedia: https://en.wikipedia.org/wiki/ANSI_escape_code However I recall that you don't like adding references to Wiki-sensei. Please feel free to discard this idea if you don't like it. > Committed with those changes. This closes the commit fest item. Thanks for the addition. -- Michael
Attachment
On 2020-03-30 10:03, Michael Paquier wrote: > On Sun, Mar 29, 2020 at 02:55:37PM +0200, Juan José Santamaría Flecha wrote: >> Add it to the tests done when PG_COLOR is "auto". > > FWIW, I am not sure that it is a good idea to stick into the code > knowledge inherent to TERM. That would likely rot depending on how > terminals evolve in the future, and it is easy to test if a terminal > supports color or not but just switching PG_COLOR in a given > environment and look at the error message produced by anything > able to support coloring. There could be some value in this, I think. Other systems also do this in some variant. However, it's unclear to me to what extent this is legacy behavior or driven by current needs. I'd be willing to refine this, but it should be based on some actual needs. What terminals (or terminal-like things) don't support color, and how do we detect them? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-03-30 10:08, Michael Paquier wrote: > On Sun, Mar 29, 2020 at 11:56:15AM +0200, Peter Eisentraut wrote: >> I didn't do this because it would create additional complications in the man >> pages. But there is now an index entry, so it's possible to find more >> information. > > Cannot you add a link to the page for color support in each one of > them? That seems more user-friendly to me. Do you have a specific phrasing or look in mind? >> I'm not sure how to do that. The full list of possible values is huge, and >> exactly what is supported depends on the terminal. > > An idea is to add a reference to SGR parameters directly from > wikipedia: > https://en.wikipedia.org/wiki/ANSI_escape_code > However I recall that you don't like adding references to > Wiki-sensei. Please feel free to discard this idea if you don't like > it. Yeah, we could perhaps do this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Apr 01, 2020 at 03:52:17PM +0200, Peter Eisentraut wrote: > On 2020-03-30 10:08, Michael Paquier wrote: >> Cannot you add a link to the page for color support in each one of >> them? That seems more user-friendly to me. > > Do you have a specific phrasing or look in mind? I actually do. Please see the attached, which seems to bring more consistency across all the docs for all the tools. >> An idea is to add a reference to SGR parameters directly from >> wikipedia: >> https://en.wikipedia.org/wiki/ANSI_escape_code >> However I recall that you don't like adding references to >> Wiki-sensei. Please feel free to discard this idea if you don't like >> it. > > Yeah, we could perhaps do this. Actually, the standard ECMA-48 could just be directly used for that: https://www.ecma-international.org/publications/standards/Ecma-048.htm So, what do you think? -- Michael