Horton

Thread

Commits

  1. Document color support

  1. color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2019-12-31T10:40:28Z

    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

  2. Re: color by default

    Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> — 2019-12-31T12:13:32Z

    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

  3. Re: color by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2019-12-31T13:35:39Z

    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

  4. Re: color by default

    Abel Abraham Camarillo Ojeda <acamari@verlet.org> — 2019-12-31T13:52:33Z

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

  5. Re: color by default

    Daniel Gustafsson <daniel@yesql.se> — 2019-12-31T13:59:04Z

    > 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

  6. Re: color by default

    Andreas Joseph Krogh <andreas@visena.com> — 2019-12-31T14:12:34Z

    På tirsdag 31. desember 2019 kl. 14:35:39, skrev Tom Lane <tgl@sss.pgh.pa.us 
<mailto: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

  7. Re: color by default

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2019-12-31T15:18:00Z

    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

  8. Re: color by default

    Isaac Morland <isaac.morland@gmail.com> — 2019-12-31T15:46:43Z

    On Tue, 31 Dec 2019 at 10:18, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

Per https://no-colors.org (thanks for the link) it seems pretty clear
>

https://no-color.org

  9. Re: color by default

    José Luis Tallón <jltallon@adv-solutions.net> — 2019-12-31T17:32:25Z

    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.

  10. Re: color by default

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2020-01-02T23:38:09Z

    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

  11. Re: color by default

    Robert Haas <robertmhaas@gmail.com> — 2020-01-03T18:10:30Z

    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

  12. Re: color by default

    Jeff Janes <jeff.janes@gmail.com> — 2020-01-03T20:25:47Z

    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

  13. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-01-06T05:38:24Z

    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

  14. Re: color by default

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2020-01-06T07:26:39Z

    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

  15. Re: color by default

    Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> — 2020-03-02T12:00:44Z

    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

Regards,

Juan José Santamaría Flecha

  16. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-03-03T05:31:01Z

    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

  17. Re: color by default

    Bruce Momjian <bruce@momjian.us> — 2020-03-20T02:15:57Z

    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 +

  18. Re: color by default

    Bruce Momjian <bruce@momjian.us> — 2020-03-21T02:55:22Z

    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 +

  19. Re: color by default

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-03-21T03:15:07Z

    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

  20. Re: color by default

    Bruce Momjian <bruce@momjian.us> — 2020-03-21T03:22:07Z

    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 +

  21. Re: color by default

    Jonah H. Harris <jonah.harris@gmail.com> — 2020-03-21T04:25:28Z

    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

  22. Re: color by default

    Isaac Morland <isaac.morland@gmail.com> — 2020-03-21T13:30:19Z

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

  23. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-03-23T05:04:10Z

    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

  24. Re: color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-03-23T08:32:08Z

    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

  25. Re: color by default

    Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> — 2020-03-24T14:34:34Z

    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

  26. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-03-26T06:36:25Z

    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

  27. Re: color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-03-29T09:56:15Z

    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

  28. Re: color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-03-29T09:56:51Z

    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

  29. Re: color by default

    Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> — 2020-03-29T12:55:37Z

    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

  30. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-03-30T08:03:46Z

    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

  31. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-03-30T08:08:16Z

    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

  32. Re: color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-04-01T13:50:42Z

    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

  33. Re: color by default

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2020-04-01T13:52:17Z

    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

  34. Re: color by default

    Michael Paquier <michael@paquier.xyz> — 2020-04-02T07:22:55Z

    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