| Message ID | 20230228145934.4182166-1-felipe.contreras@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 7ee1af8cb8b97385fc4e603bc024d877def5adb4 |
| Headers | show |
| Series | [try2] completion: prompt: use generic colors | expand |
Felipe Contreras <felipe.contreras@gmail.com> writes: > When the prompt command mode was introduced in 1bfc51ac81 (Allow > __git_ps1 to be used in PROMPT_COMMAND, 2012-10-10) the assumption was > that it was necessary in order to properly add colors to PS1 in bash, > but this wasn't true. > > It's true that the \[ \] markers add the information needed to properly > calculate the width of the prompt, and they have to be added directly to > PS1, a function returning them doesn't work. > > But that is because bash coverts the \[ \] markers in PS1 to \001 \002, > which is what readline ultimately needs in order to calculate the width. > > We don't need bash to do this conversion, we can use \001 \002 > ourselves, and then the prompt command mode is not necessary to display > colors. > > This is what functions returning colors are supposed to do [1]. > > [1] http://mywiki.wooledge.org/BashFAQ/053 > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> > --- > contrib/completion/git-prompt.sh | 19 +++++++------------ > t/t9903-bash-prompt.sh | 8 ++++---- > 2 files changed, 11 insertions(+), 16 deletions(-) Comments from those who use colored prompt and who are familiar with the mechansim used to implement this? As I do not use the feature at all and haven't been following it, seeing independent support would help the topic. Thanks. > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh > index 57972c2845..76ee4ab1e5 100644 > --- a/contrib/completion/git-prompt.sh > +++ b/contrib/completion/git-prompt.sh > @@ -100,9 +100,7 @@ > # > # If you would like a colored hint about the current dirty state, set > # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on > -# the colored output of "git status -sb" and are available only when > -# using __git_ps1 for PROMPT_COMMAND or precmd in Bash, > -# but always available in Zsh. > +# the colored output of "git status -sb". > # > # If you would like __git_ps1 to do nothing in the case when the current > # directory is set up to be ignored by git, then set > @@ -259,12 +257,12 @@ __git_ps1_colorize_gitstring () > local c_lblue='%F{blue}' > local c_clear='%f' > else > - # Using \[ and \] around colors is necessary to prevent > + # Using \001 and \002 around colors is necessary to prevent > # issues with command line editing/browsing/completion! > - local c_red='\[\e[31m\]' > - local c_green='\[\e[32m\]' > - local c_lblue='\[\e[1;34m\]' > - local c_clear='\[\e[0m\]' > + local c_red=$'\001\e[31m\002' > + local c_green=$'\001\e[32m\002' > + local c_lblue=$'\001\e[1;34m\002' > + local c_clear=$'\001\e[0m\002' > fi > local bad_color=$c_red > local ok_color=$c_green > @@ -574,11 +572,8 @@ __git_ps1 () > b="\${__git_ps1_branch_name}" > fi > > - # NO color option unless in PROMPT_COMMAND mode or it's Zsh > if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then > - if [ $pcmode = yes ] || [ -n "${ZSH_VERSION-}" ]; then > - __git_ps1_colorize_gitstring > - fi > + __git_ps1_colorize_gitstring > fi > > local f="$h$w$i$s$u$p" > diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh > index d459fae655..d667dda654 100755 > --- a/t/t9903-bash-prompt.sh > +++ b/t/t9903-bash-prompt.sh > @@ -13,10 +13,10 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > . "$GIT_BUILD_DIR/contrib/completion/git-prompt.sh" > > actual="$TRASH_DIRECTORY/actual" > -c_red='\\[\\e[31m\\]' > -c_green='\\[\\e[32m\\]' > -c_lblue='\\[\\e[1;34m\\]' > -c_clear='\\[\\e[0m\\]' > +c_red='\001\e[31m\002' > +c_green='\001\e[32m\002' > +c_lblue='\001\e[1;34m\002' > +c_clear='\001\e[0m\002' > > test_expect_success 'setup for prompt tests' ' > git init otherrepo &&
On Wed, Mar 1, 2023 at 1:34 PM Junio C Hamano <gitster@pobox.com> wrote: > Felipe Contreras <felipe.contreras@gmail.com> writes: > > We don't need bash to do this conversion, we can use \001 \002 > > ourselves, and then the prompt command mode is not necessary to display > > colors. > Comments from those who use colored prompt and who are familiar with > the mechansim used to implement this? As I do not use the feature > at all and haven't been following it, seeing independent support > would help the topic. At least in try1 Justin Donnelly reported success [1]. And you don't need to use the feature to check that this patch obviously works, it's easy to test. All you need to see the original problem is a short (as in width) terminal, or a long enough typed line (I type a lot of d's until surpassing the width). This prompt should easily show the original problem: PS1='\w (\e[31mfoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\e[m) > ' With the marks proposed by the patch, the problem is gone: PS1='\w (\001\e[31m\002foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\001\e[m\002) > ' Of course, in order to test, PROMPT_COMMAND shouldn't override PS1. Cheers. [1] https://lore.kernel.org/git/CAGTqyRzZ-cOp1C4f30fGFhjH1hh5U137=77pEHp_bmBzNcmTCw@mail.gmail.com/
On 01/03/2023 21:27, Felipe Contreras wrote: >>> We don't need bash to do this conversion, we can use \001 \002 >>> ourselves, and then the prompt command mode is not necessary to display >>> colors. > >> Comments from those who use colored prompt and who are familiar with >> the mechansim used to implement this? As I do not use the feature >> at all and haven't been following it, seeing independent support >> would help the topic. > > At least in try1 Justin Donnelly reported success [1]. I've played around a bit with this patch, and it seems to work as advertised.
Joakim Petersen <joak-pet@online.no> writes: > I've played around a bit with this patch, and it seems to work as > advertised. As the change itself is so trivial and likely to exhibit problem immediatly if it were not right (e.g. for some version of the shell but not for others), let's queue it. Thanks.
On Thu, Mar 16, 2023 at 5:00 PM Junio C Hamano <gitster@pobox.com> wrote: > > Joakim Petersen <joak-pet@online.no> writes: > > > I've played around a bit with this patch, and it seems to work as > > advertised. > > As the change itself is so trivial and likely to exhibit problem > immediatly if it were not right (e.g. for some version of the shell > but not for others), let's queue it. For the record, it's not even the shell, it's the readline library, and those markers are present since the initial import in 2011: https://git.savannah.gnu.org/cgit/readline.git/tree/readline.h?id=06cd36cdc90634c88636a6d09230c573078ead0e#n282 #define RL_PROMPT_START_IGNORE '\001' #define RL_PROMPT_END_IGNORE '\002'
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh index 57972c2845..76ee4ab1e5 100644 --- a/contrib/completion/git-prompt.sh +++ b/contrib/completion/git-prompt.sh @@ -100,9 +100,7 @@ # # If you would like a colored hint about the current dirty state, set # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on -# the colored output of "git status -sb" and are available only when -# using __git_ps1 for PROMPT_COMMAND or precmd in Bash, -# but always available in Zsh. +# the colored output of "git status -sb". # # If you would like __git_ps1 to do nothing in the case when the current # directory is set up to be ignored by git, then set @@ -259,12 +257,12 @@ __git_ps1_colorize_gitstring () local c_lblue='%F{blue}' local c_clear='%f' else - # Using \[ and \] around colors is necessary to prevent + # Using \001 and \002 around colors is necessary to prevent # issues with command line editing/browsing/completion! - local c_red='\[\e[31m\]' - local c_green='\[\e[32m\]' - local c_lblue='\[\e[1;34m\]' - local c_clear='\[\e[0m\]' + local c_red=$'\001\e[31m\002' + local c_green=$'\001\e[32m\002' + local c_lblue=$'\001\e[1;34m\002' + local c_clear=$'\001\e[0m\002' fi local bad_color=$c_red local ok_color=$c_green @@ -574,11 +572,8 @@ __git_ps1 () b="\${__git_ps1_branch_name}" fi - # NO color option unless in PROMPT_COMMAND mode or it's Zsh if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then - if [ $pcmode = yes ] || [ -n "${ZSH_VERSION-}" ]; then - __git_ps1_colorize_gitstring - fi + __git_ps1_colorize_gitstring fi local f="$h$w$i$s$u$p" diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index d459fae655..d667dda654 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -13,10 +13,10 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME . "$GIT_BUILD_DIR/contrib/completion/git-prompt.sh" actual="$TRASH_DIRECTORY/actual" -c_red='\\[\\e[31m\\]' -c_green='\\[\\e[32m\\]' -c_lblue='\\[\\e[1;34m\\]' -c_clear='\\[\\e[0m\\]' +c_red='\001\e[31m\002' +c_green='\001\e[32m\002' +c_lblue='\001\e[1;34m\002' +c_clear='\001\e[0m\002' test_expect_success 'setup for prompt tests' ' git init otherrepo &&
When the prompt command mode was introduced in 1bfc51ac81 (Allow __git_ps1 to be used in PROMPT_COMMAND, 2012-10-10) the assumption was that it was necessary in order to properly add colors to PS1 in bash, but this wasn't true. It's true that the \[ \] markers add the information needed to properly calculate the width of the prompt, and they have to be added directly to PS1, a function returning them doesn't work. But that is because bash coverts the \[ \] markers in PS1 to \001 \002, which is what readline ultimately needs in order to calculate the width. We don't need bash to do this conversion, we can use \001 \002 ourselves, and then the prompt command mode is not necessary to display colors. This is what functions returning colors are supposed to do [1]. [1] http://mywiki.wooledge.org/BashFAQ/053 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> --- contrib/completion/git-prompt.sh | 19 +++++++------------ t/t9903-bash-prompt.sh | 8 ++++---- 2 files changed, 11 insertions(+), 16 deletions(-)