|
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