bash completion with colour hints

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

bash completion with colour hints

From: Simon Oosthoek <hidden>
Date: 2016-06-15 22:54:52

Hi Shawn

I only recently found the __git_ps1 function, but it wasn't directly 
able to replace my own contraption. I've modified the version I found 
after installing bash-completion in debian 6.

The patch is attached, it contains an escape character, so it is hard to 
include in plain text. I've gzipped it for convenience...

This is only a first step, I had a hard time figuring out what exactly 
the one-letter variables were doing (and still a bit unclear), so I'm 
sure this can be improved!

Anyway, the functionality of this patch is to show the output in green 
if the repo is up to date and red or other colours if it isn't.

Cheers

Simon

Re: bash completion with colour hints

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:54:52

Hi Simon,

Could you follow the guidelines in Documentation/SubmittingPatches, so
that the patch can be considered for inclusion?
quoted hunk
--- git-orig-bak	2012-09-26 16:39:47.000000000 +0200
+++ git-bashcompletion	2012-09-26 16:50:57.000000000 +0200
@@ -59,6 +59,9 @@
 #       per-repository basis by setting the bash.showUpstream config
 #       variable.
 #
+#       If you would like an additional hint in colour in your prompt
+#       set GIT_PS1_SHOWCOLORHINT to a nonempty value. Currently
+#       the colours are hardcoded in the function...
Nit: I think it's spelt "color" everywhere else in git.
quoted hunk
 #
 # To submit patches:
 #
@@ -302,9 +305,35 @@
 				__git_ps1_show_upstream
 			fi
 		fi
-
+	
Whitespace damage.
+		local c_red=' [31m'
+		local c_yellow=' [33m'
+		local c_lblue=' [1,34m'
+		local c_green=' [32m'
+		local c_purple=' [35m'
+		local c_cyan=' [36m'
+		local c_clear=' [0m'
+		local printf_format="${1:- (%s)}"
+
+		if [ -n "${GIT_PS1_SHOWCOLORHINT-}" ]; then
+			if [ "$w" != "*" ]; then
+				printf_format="$c_green$printf_format$c_clear"
+			else
+				printf_format="$c_red$printf_format$c_clear"
+			fi
+			if [ -n "$i" ]; then
+				i="$c_yellow$i$c_clear"
+			fi
+			if [ -n "$s" ]; then
+				s="$c_lblue$i$c_clear"
+			fi
+			if [ -n "$u" ]; then
+				u="$c_purple$i$c_clear"
+			fi
+		fi
+			
 		local f="$w$i$s$u"
-		printf "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
+		echo $(printf "$printf_format" "$c${b##refs/heads/}${f:+ $f}$r$p")
 	fi
 }
Looks okay from a glance.

Ram

Re: bash completion with colour hints

From: Simon Oosthoek <hidden>
Date: 2016-06-15 22:54:52

On 26/09/12 17:24, Ramkumar Ramachandra wrote:
Hi Simon,

Could you follow the guidelines in Documentation/SubmittingPatches, so
that the patch can be considered for inclusion?
Hi Ram, thanks for your feedback.

I gather now that this file is part of the entire git tree ;-)

this is my first time to submit a patch to git and frankly I coded this
up very quickly and did only a small test.

I read the guide and now I have some questions:

- It suggests to use the oldest commit that contains the "bug" and can
support the fix. This would be the very first mention of __git_ps1
function I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585
However, I guess that although I have been using something similar since
about 2009, I should at least base it on the relatively new
git-prompt.sh file, is this a correct interpretation of the guide?
(BTW, I wonder how this will affect ultimately the current master?)

- I read that git-prompt.sh is meant to support bash and zsh, I have
only tested it on bash. Should I attempt to test it on zsh or is there a
kind person with zsh as his/her shell to test it for me?

My instinct is to just apply my patch to the current master, but I'm
open to starting from a different base, but I'm too new to the tree to
know which one, any suggestions?


quoted
--- git-orig-bak	2012-09-26 16:39:47.000000000 +0200
+++ git-bashcompletion	2012-09-26 16:50:57.000000000 +0200
@@ -59,6 +59,9 @@
 #       per-repository basis by setting the bash.showUpstream config
 #       variable.
 #
+#       If you would like an additional hint in colour in your prompt
+#       set GIT_PS1_SHOWCOLORHINT to a nonempty value. Currently
+#       the colours are hardcoded in the function...
Nit: I think it's spelt "color" everywhere else in git.
I can adapt ;-)
quoted
+		local c_red=' [31m'
+		local c_yellow=' [33m'
+		local c_lblue=' [1,34m'
+		local c_green=' [32m'
+		local c_purple=' [35m'
+		local c_cyan=' [36m'
+		local c_clear=' [0m'
+		local printf_format="${1:- (%s)}"
+
+		if [ -n "${GIT_PS1_SHOWCOLORHINT-}" ]; then
+			if [ "$w" != "*" ]; then
+				printf_format="$c_green$printf_format$c_clear"
+			else
+				printf_format="$c_red$printf_format$c_clear"
+			fi
+			if [ -n "$i" ]; then
+				i="$c_yellow$i$c_clear"
+			fi
+			if [ -n "$s" ]; then
+				s="$c_lblue$i$c_clear"
+			fi
+			if [ -n "$u" ]; then
+				u="$c_purple$i$c_clear"
+			fi
+		fi
+			
 		local f="$w$i$s$u"
-		printf "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
+		echo $(printf "$printf_format" "$c${b##refs/heads/}${f:+ $f}$r$p")
I'm still in some doubt over this last line, including the color codes
is confusing me...

I'll go ahead and try some more polishing and whatever more comes as
suggestions. Is it ok to bother the list with intermediate stuff in this
thread?

Cheers

Simon
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help