git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Eduardo D'Avila <erdavila@gmail.com>
Cc: "Øystein Walle" <oystwa@gmail.com>,
	git@vger.kernel.org,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	"Ramkumar Ramachandra" <artagnon@gmail.com>,
	"Simon Oosthoek" <s.oosthoek@xs4all.nl>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH 2/4] git-prompt.sh: refactor colored prompt code
Date: Sun, 23 Jun 2013 16:51:57 +0200	[thread overview]
Message-ID: <20130623145157.GN20052@goldbirke> (raw)
In-Reply-To: <CAOz-D1+LoAnoRLgnyRYtq5LQR32RyXp4RR2M5pPTaxaGcXM4yg@mail.gmail.com>

On Sat, Jun 22, 2013 at 01:45:38PM -0300, Eduardo D'Avila wrote:
> 2013/6/22 Øystein Walle <oystwa@gmail.com>:
> > I've gotten the impression it's better to use tput to generate the escape
> > sequences instead of hardcoding them. So something like:
> >
> > local c_red='\['"$(tput setaf 1)"'\]'
> > local c_green='\['"$(tput setaf 2)"'\]'
> > local c_green='\['"$(tput setaf 4)"'\]'
> > local c_clear='\['"$(tput sgr0)"'\]'
> >
> > which is technically cleaner, if not visually.
> >
> > The problem with that approach is that tput will be run several times for
> > each prompt, so it would be best if the color variables were global. Another
> > thing is that you rely on tput being available.
> 
> Are there any guidelines regarding global shell script variables?

There are a couple of global variables in the completion script, they
are all prefixed with "__git_", e.g. $__git_porcelain_commands.  In
the prompt script we don't have any global variables at the moment,
but if we were to create some, then they should be prefixed similarly.
Or perhaps with "__git_ps1_".  Anyway, in case of a global variable
I'd spell out "color" completely instead of abbreviating it as "c".

> I'm considering doing this:
>    __git_c_red="\[$(tput setaf 1 || echo -e '\e[31m')\]"
> which handles the case where tput is not available.

To me 'tput setaf 1' is just a little bit less greek than '\e[31m'.

I'm wary of relying on tput's availability.  It's part of ncurses,
which is an essential package in many (most? all?) linux distros, but
I don't know how it is with other supported platforms.  So I think
we'd have to stick to the hard-coded escape sequences as a fallback
anyway.  And if we can't get rid of these escape sequences completely,
then I don't really see the point of using tput, especially
considering the additional delay that would be caused by fork()ing
four subshells and fork()+exec()ing four external commands on Windows.

However, I don't know much about the caveats of terminals, so I can't
judge the benefits of using tput instead of the escape sequences.  


Gábor

  reply	other threads:[~2013-06-23 14:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21  2:25 [PATCH 0/4] git-prompt: cleaning and improvement Eduardo R. D'Avila
2013-06-21  2:25 ` [PATCH 1/4] t9903: add tests for git-prompt pcmode Eduardo R. D'Avila
2013-06-22 13:06   ` SZEDER Gábor
2013-06-22 16:32     ` Eduardo D'Avila
2013-06-23  7:39       ` Junio C Hamano
2013-06-24 16:21       ` SZEDER Gábor
2013-06-21  2:25 ` [PATCH 2/4] git-prompt.sh: refactor colored prompt code Eduardo R. D'Avila
2013-06-22 14:37   ` Øystein Walle
2013-06-22 16:45   ` Eduardo D'Avila
2013-06-23 14:51     ` SZEDER Gábor [this message]
2013-06-25  1:21       ` Eduardo R. D'Avila
2013-06-21  2:25 ` [PATCH 3/4] git-prompt.sh: do not print duplicate clean color code Eduardo R. D'Avila
2013-06-22 13:26   ` SZEDER Gábor
2013-06-21  2:25 ` [PATCH 4/4] git-prompt.sh: add missing information in comments Eduardo R. D'Avila
2013-06-22 13:40   ` SZEDER Gábor

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=20130623145157.GN20052@goldbirke \
    --to=szeder@ira.uka.de \
    --cc=artagnon@gmail.com \
    --cc=erdavila@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=oystwa@gmail.com \
    --cc=s.oosthoek@xs4all.nl \
    /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).