git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Spiers <git@adamspiers.org>
To: Jeff King <peff@peff.net>
Cc: git list <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Stefano Lattarini <stefano.lattarini@gmail.com>
Subject: Re: [PATCH v4 3/6] Color skipped tests blue
Date: Sun, 11 Nov 2012 02:04:14 +0000	[thread overview]
Message-ID: <20121111020355.GA11565@gmail.com> (raw)
In-Reply-To: <20120921061325.GA15867@sigill.intra.peff.net>

On Fri, Sep 21, 2012 at 02:13:25AM -0400, Jeff King wrote:
> On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
> 
> >  t/test-lib.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 5293830..78c88c2 100755
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -182,13 +182,13 @@ then
> >  		error)
> >  			tput bold; tput setaf 1;; # bold red
> >  		skip)
> > -			tput bold; tput setaf 2;; # bold green
> > +			tput setaf 4;;            # blue
> >  		warn)
> >  			tput bold; tput setaf 3;; # bold yellow
> >  		pass)
> >  			tput setaf 2;;            # green
> >  		info)
> > -			tput setaf 3;;            # brown
> > +			tput setaf 3;;            # yellow/brown
> 
> I happened to be running a test script with "-v" earlier today, and I
> noticed that the "expecting success..." dump of the test contents is
> also yellow. By your new rules, shouldn't it be blue?
> 
> I think it is matching the "info" type, which from the discussion should
> be blue, no?

It uses the "default" colour:

    say >&3 "expecting success: $2"

where say is defined:

    say () {
            say_color info "$*"
    }

Many other messages are output in this default colour too, and I never
proposed to change it.  The only time in the discussion where blue was
associated with "info" was in this sentence I wrote in the
commit message for the patch altering the colour of "skip" messages:

   "However, it's more informational than cautionary, so instead we
    use blue which is a universal color for information signs."

Whilst it could also be applied to "info", I don't think it would be a
good idea to have the "skip" and "info" colours *both* as bold blue.
It seems to me more important that the "skip" messages should visually
stand out more than "info", since they are rarer and a more notable
level of information than the latter (especially if --verbose is
used).  Additionally, yellow is already somewhat overloaded (yellow
for "info" and bold yellow for "warn").  Therefore I would suggest
changing "info" to perhaps bold white or bold cyan.  Or "skip" could
be magenta and "info" blue.  But now we are heading down a slippery
slope; it'll be near impossible to please everyone.  Any final
thoughts?

> Maybe it is just my terminal. I see it is labeled as "brown" here, but
> it looks very yellow (and I am using the stock xterm colors. According
> to:
> 
>   https://en.wikipedia.org/wiki/ANSI_colors
> 
> It looks it really is brown on some platforms.

Yes, it can be.

> I'm not sure if it is
> worth worrying about.  I don't really want to get into configurable
> colors just for the test-suite output.

Agreed.  There is no indisputably correct combination.  However, I
think that, modulo a tweak for the above, we are definitely in the
right ball park.  The main thing is that the traffic light colour
scheme is adhered to, and that different types of message are clearly
visually separated, with more important ones standing out more than
less important ones.

  reply	other threads:[~2012-11-11  2:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17 11:50 [PATCH] Make test output coloring more intuitive Adam Spiers
2012-09-17 20:11 ` Jeff King
2012-09-18 21:21   ` Adam Spiers
2012-09-19 20:02   ` Stefano Lattarini
2012-09-19 20:12     ` Adam Spiers
2012-09-19 20:13       ` Jeff King
2012-09-19 20:24         ` [PATCH v4 3/6] Color skipped tests blue Adam Spiers
2012-09-20  5:48           ` Johannes Sixt
2012-09-20  9:04             ` Adam Spiers
2012-09-20  9:08             ` [PATCH v5 3/3] Color skipped tests bold blue Adam Spiers
2012-09-20 10:08               ` Stefano Lattarini
2012-09-20 16:20                 ` Junio C Hamano
2012-09-21  6:13           ` [PATCH v4 3/6] Color skipped tests blue Jeff King
2012-11-11  2:04             ` Adam Spiers [this message]
2012-09-17 20:50 ` [PATCH] Make test output coloring more intuitive Junio C Hamano
2012-09-18 21:36   ` Adam Spiers
2012-09-18 21:59     ` Jeff King
2012-09-18 22:14       ` Adam Spiers
2012-09-19 17:15     ` [PATCH v2 0/6] make " Adam Spiers
2012-09-19 17:15       ` [PATCH v2 1/6] Change the color of individual known breakages Adam Spiers
2012-09-19 17:15       ` [PATCH v2 2/6] Make 'not ok $count - $message' consistent with 'ok $count - $message' Adam Spiers
2012-09-19 17:50         ` Jeff King
2012-09-19 23:39         ` Junio C Hamano
2012-09-19 23:45           ` Adam Spiers
2012-09-19 17:15       ` [PATCH v2 3/6] Color skipped tests the same as informational messages Adam Spiers
2012-09-19 17:15       ` [PATCH v2 4/6] Refactor mechanics of testing in a sub test-lib Adam Spiers
2012-09-19 17:56         ` Jeff King
2012-09-19 18:44           ` Adam Spiers
2012-09-19 18:49             ` [PATCH v3 " Adam Spiers
2012-09-19 18:49               ` [PATCH v3 5/6] Test the test framework more thoroughly Adam Spiers
2012-09-19 18:49               ` [PATCH v3 6/6] Treat unexpectedly fixed known breakages more seriously Adam Spiers
2012-09-20 21:13               ` [PATCH v3 4/6] Refactor mechanics of testing in a sub test-lib Junio C Hamano
2012-09-19 19:37             ` [PATCH v2 " Jeff King
2012-09-19 20:15               ` Adam Spiers
2012-09-19 17:15       ` [PATCH v2 5/6] Test the test framework more thoroughly Adam Spiers
2012-09-19 17:15       ` [PATCH v2 6/6] Treat unexpectedly fixed known breakages more seriously Adam Spiers
2012-09-19 18:05       ` [PATCH v2 0/6] make test output coloring more intuitive Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121111020355.GA11565@gmail.com \
    --to=git@adamspiers.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=stefano.lattarini@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).