|
129 | 129 | # strings (SGR color sequences) when calculating the on-screen |
130 | 130 | # prompt width, to maintain correct input editing at the prompt. |
131 | 131 | # |
132 | | -# Currently there's no support for different markers, so if editing |
133 | | -# behaves weird when using colors in __git_ps1, then the solution |
134 | | -# is either to disable colors, or, in some shells which only care |
135 | | -# about the width of the last prompt line (e.g. busybox-ash), |
136 | | -# ensure the git output is not at the last line, maybe like so: |
| 132 | +# To replace or disable the 0-width markers, set GIT_PS1_COLOR_PRE |
| 133 | +# and GIT_PS1_COLOR_POST to other markers, or empty (nul) to not |
| 134 | +# use markers. For instance, some shells support '\[' and '\]' as |
| 135 | +# start/end markers in PS1 - when invoking __git_ps1 with 3/4 args, |
| 136 | +# but it may or may not work in command substitution mode. YMMV. |
| 137 | +# |
| 138 | +# If the shell doesn't support 0-width markers and editing behaves |
| 139 | +# incorrectly when using colors in __git_ps1, then, other than |
| 140 | +# disabling color, it might be solved using multi-line prompt, |
| 141 | +# where the git status is not at the last line, e.g.: |
137 | 142 | # PS1='\n\w \u@\h$(__git_ps1 " (%s)")\n\$ ' |
138 | 143 |
|
139 | 144 | # check whether printf supports -v |
@@ -309,8 +314,8 @@ __git_ps1_colorize_gitstring () |
309 | 314 | # \001 (SOH) and \002 (STX) are 0-width substring markers |
310 | 315 | # which bash/readline identify while calculating the prompt |
311 | 316 | # on-screen width - to exclude 0-screen-width esc sequences. |
312 | | - local c_pre="${__git_SOH}${__git_ESC}[" |
313 | | - local c_post="m${__git_STX}" |
| 317 | + local c_pre="${GIT_PS1_COLOR_PRE-$__git_SOH}${__git_ESC}[" |
| 318 | + local c_post="m${GIT_PS1_COLOR_POST-$__git_STX}" |
314 | 319 |
|
315 | 320 | local c_red="${c_pre}31${c_post}" |
316 | 321 | local c_green="${c_pre}32${c_post}" |
|
0 commit comments