git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Thomas Rast <trast@inf.ethz.ch>,
	Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/6] prompt: don't scream continuation state
Date: Tue, 4 Jun 2013 00:38:37 -0400	[thread overview]
Message-ID: <20130604043836.GA3931@sigill.intra.peff.net> (raw)
In-Reply-To: <CALkWK0=5XecaMpPPQgvJZTwR2QUUWVqbZK5p7af9R1HjA0U=OQ@mail.gmail.com>

On Tue, Jun 04, 2013 at 09:14:23AM +0530, Ramkumar Ramachandra wrote:

> Jeff King wrote:
> > It seems silly to argue about output formats when we are writing a
> > prompt in a convenient Turing-complete scripting language already.
> > What about something like:
> 
> Could you have a look at __git_ps1_colorize_gitstring from
> rr/zsh-color-prompt in pu?  In the general case, wouldn't the user
> need to re-implement this entire function (with so many variables) in
> her ~/.zshrc?  Isn't it horribly painful for too little gain?

It is a lot of ugly code, but then, complexity and flexibility are a
tradeoff. You would not _have_ to use a custom function at all. But if
we make it an option, and leave the existing code as the default
function, then only those who want it have to use it.

Even better, we can hit a middle ground by abstracting away some of the
complexity.  You could probably write colorize() function to handle
colorizing a particular string (and handle bash/zsh magic), and then
pull the whole "which color is the branch" function into a
colorize_branch(), and so forth.

I haven't looked that closely, so there may be hidden troubles awaiting,
but I don't see why you couldn't ultimately let the user write something
like:

  __git_ps1_printer() {
          echo ' ('
          test "$bare" = t && echo "BARE:"; # or "bare:" :)
          color_branch "$(short_ref $branch)" "$detached"
          test "$wt_changes" = t && colorize red "*"
          ...
          echo ')'
  }

And if that is too much, you can abstract bits of it out. The point is
that if we can expose the lowest-level details, we can compose functions
around them at whatever level is appropriate, and callers can mix and
match for the balance of complexity and flexibility they want.

Perhaps it is overkill, but I also think it may make the code itself
more readable. For example, I put a "..." above because the next line
would handle this:

  if [ -n "$i" ]; then
          gitstring="$gitstring\[$ok_color\]$i"
  fi

I have no clue what that does, or what the global variable "$i"
contains. Reading through __git_ps1, it looks like it will be "+" for
index changes. Being able to write:

  test "$index_changes" = t && colorize green "+"

seems much more readable to me. And we could probably compose a:

  colorize_diff_state() {
          test "$wt_changes" = t && colorize red "*"
          test "$index_changes" = t && colorize green "+"
  }

for people who just want to take the default colors and characters.

-Peff

  reply	other threads:[~2013-06-04  4:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-02 14:03 [PATCH 0/6] Minor prompt, completion cleanups Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 1/6] prompt: don't scream continuation state Ramkumar Ramachandra
2013-06-03  8:58   ` Thomas Rast
2013-06-03  9:47     ` Ramkumar Ramachandra
2013-06-03 21:15       ` Jeff King
2013-06-04  3:44         ` Ramkumar Ramachandra
2013-06-04  4:38           ` Jeff King [this message]
2013-06-04  5:59             ` Junio C Hamano
2013-06-03 17:23     ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 2/6] completion: add common options for rev-parse Ramkumar Ramachandra
2013-06-07 15:33   ` Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 3/6] completion: add common options for blame Ramkumar Ramachandra
2013-06-03  9:03   ` Thomas Rast
2013-06-03  9:32     ` Ramkumar Ramachandra
2013-06-03 18:07       ` SZEDER Gábor
2013-06-03 18:34         ` Junio C Hamano
2013-06-06  9:58       ` Peter Krefting
2013-06-03 17:24     ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 4/6] completion: correct completion for format-patch Ramkumar Ramachandra
2013-06-02 17:20   ` Felipe Contreras
2013-06-02 17:29     ` Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 5/6] completion: clarify difftool completion Ramkumar Ramachandra
2013-06-03 17:29   ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 6/6] completion: clarify ls-tree, archive, show completion Ramkumar Ramachandra
2013-06-03 17:33   ` Junio C Hamano
2013-06-04  3:49     ` Ramkumar Ramachandra
2013-06-04  6:01       ` Junio C Hamano
2013-06-03 17:58   ` Junio C Hamano
2013-06-03 19:25   ` SZEDER Gábor
2013-06-07 17:21     ` Ramkumar Ramachandra
2013-06-07 18:36       ` Junio C Hamano
2013-06-07 18:45       ` SZEDER Gábor
2013-06-09 20:56     ` Junio C Hamano

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=20130604043836.GA3931@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=trast@inf.ethz.ch \
    /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).