[PATCH] completion: use native ZSH array pattern matching

[PATCH] completion: use native ZSH array pattern matching

[Marco Trevisan via GitGitGadget]

From: =?UTF-8?q?Marco=20Trevisan=20=28Trevi=C3=B1o=29?= <mail@3v1n0.net>

When clearing the builtin operations on re-sourcing in the ZSH case we
can use the native ${parameters} associative array keys values to get
the currently `__gitcomp_builtin_*` operations using pattern matching
instead of using sed.

As also stated in commit 94408dc7, introducing this change the usage of
sed has some overhead implications, while ZSH can do this check just
using its native syntax.

Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
---
    completion: Use native ZSH array pattern matching
    
    When clearing the builtin operations on re-sourcing in the ZSH case we
    can use the native ${parameters} associative array keys values to get
    the currently __gitcomp_builtin_* operations using pattern matching
    instead of using sed.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-645%2F3v1n0%2Fzsh-native-operation-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-645/3v1n0/zsh-native-operation-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/645

 contrib/completion/git-completion.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 70ad04e1b2a..ad6934a3864 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -373,7 +373,7 @@ __gitcomp ()
 # Clear the variables caching builtins' options when (re-)sourcing
 # the completion script.
 if [[ -n ${ZSH_VERSION-} ]]; then
-	unset $(set |sed -ne 's/^\(__gitcomp_builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*\)=.*/\1/p') 2>/dev/null
+	unset ${(M)${(k)parameters[@]}:#__gitcomp_builtin_*} 2>/dev/null
 else
 	unset $(compgen -v __gitcomp_builtin_)
 fi

base-commit: d2ecc46c0981fb829fdfb204604ed0a2798cbe07
-- 
gitgitgadget

Re: [PATCH] completion: use native ZSH array pattern matching

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

On 2020-05-26 at 19:13:17, Marco Trevisan via GitGitGadget wrote:
> From: =?UTF-8?q?Marco=20Trevisan=20=28Trevi=C3=B1o=29?= <mail@3v1n0.net>
> 
> When clearing the builtin operations on re-sourcing in the ZSH case we
> can use the native ${parameters} associative array keys values to get
> the currently `__gitcomp_builtin_*` operations using pattern matching
> instead of using sed.
> 
> As also stated in commit 94408dc7, introducing this change the usage of
> sed has some overhead implications, while ZSH can do this check just
> using its native syntax.
> 
> Signed-off-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
> ---
>     completion: Use native ZSH array pattern matching
>     
>     When clearing the builtin operations on re-sourcing in the ZSH case we
>     can use the native ${parameters} associative array keys values to get
>     the currently __gitcomp_builtin_* operations using pattern matching
>     instead of using sed.
> 
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-645%2F3v1n0%2Fzsh-native-operation-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-645/3v1n0/zsh-native-operation-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/645
> 
>  contrib/completion/git-completion.bash | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 70ad04e1b2a..ad6934a3864 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -373,7 +373,7 @@ __gitcomp ()
>  # Clear the variables caching builtins' options when (re-)sourcing
>  # the completion script.
>  if [[ -n ${ZSH_VERSION-} ]]; then
> -	unset $(set |sed -ne 's/^\(__gitcomp_builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*\)=.*/\1/p') 2>/dev/null
> +	unset ${(M)${(k)parameters[@]}:#__gitcomp_builtin_*} 2>/dev/null
>  else
>  	unset $(compgen -v __gitcomp_builtin_)
>  fi

This file is necessarily used by both bash and zsh.  Does bash
(including the bash 3 used on macOS) happen to continue to work with
this syntax?

We've had cases in the past where despite some code running under shell
A, shell B, which also parsed file, choked on the data because it
had to parse it even though it didn't execute it.

If so, and this works there, can you mention that in your commit message
for future readers?
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH] completion: use native ZSH array pattern matching

[Carlo Marcelo Arenas Belón]

On Tue, May 26, 2020 at 11:58:34PM +0000, brian m. carlson wrote:
> 
> This file is necessarily used by both bash and zsh.  Does bash
> (including the bash 3 used on macOS) happen to continue to work with
> this syntax?

if by that you meant t9902.[150-152] to succeed with macOS bash?:

$ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
Copyright (C) 2007 Free Software Foundation, Inc.

then I think we can add (on top of master):

Tested-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>

Carlo

Re: [PATCH] completion: use native ZSH array pattern matching

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On 2020-05-27 at 06:13:59, Carlo Marcelo Arenas Belón wrote:
> On Tue, May 26, 2020 at 11:58:34PM +0000, brian m. carlson wrote:
> > 
> > This file is necessarily used by both bash and zsh.  Does bash
> > (including the bash 3 used on macOS) happen to continue to work with
> > this syntax?
> 
> if by that you meant t9902.[150-152] to succeed with macOS bash?:
> 
> $ bash --version
> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
> Copyright (C) 2007 Free Software Foundation, Inc.
> 
> then I think we can add (on top of master):
> 
> Tested-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>

Yes, that is what I meant.  I'm glad to know my question has been
answered and things work.  I'm okay with the patch as it is in that
case, although I'd give bonus points for mentioning that this syntax
doesn't regress bash.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH] completion: use native ZSH array pattern matching

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2020-05-27 at 06:13:59, Carlo Marcelo Arenas Belón wrote:
>> On Tue, May 26, 2020 at 11:58:34PM +0000, brian m. carlson wrote:
>> > 
>> > This file is necessarily used by both bash and zsh.  Does bash
>> > (including the bash 3 used on macOS) happen to continue to work with
>> > this syntax?
>> 
>> if by that you meant t9902.[150-152] to succeed with macOS bash?:
>> 
>> $ bash --version
>> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> 
>> then I think we can add (on top of master):
>> 
>> Tested-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
>
> Yes, that is what I meant.  I'm glad to know my question has been
> answered and things work.  I'm okay with the patch as it is in that
> case, although I'd give bonus points for mentioning that this syntax
> doesn't regress bash.

True.  And we would want to also have tested-by on more recent
versions of bash, no?

Re: [PATCH] completion: use native ZSH array pattern matching

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

On 2020-05-28 at 15:54:49, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > Yes, that is what I meant.  I'm glad to know my question has been
> > answered and things work.  I'm okay with the patch as it is in that
> > case, although I'd give bonus points for mentioning that this syntax
> > doesn't regress bash.
> 
> True.  And we would want to also have tested-by on more recent
> versions of bash, no?

Sure, such testing would be welcome, but I believe those are tested with
our tests on most platforms.  macOS is special because it uses the last
GPLv2 version of bash, which is less capable in some ways.  I assumed
that bash would not be more likely to break here in newer versions, but
perhaps I shouldn't make that assumption.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH] completion: use native ZSH array pattern matching

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2020-05-28 at 15:54:49, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> > Yes, that is what I meant.  I'm glad to know my question has been
>> > answered and things work.  I'm okay with the patch as it is in that
>> > case, although I'd give bonus points for mentioning that this syntax
>> > doesn't regress bash.
>> 
>> True.  And we would want to also have tested-by on more recent
>> versions of bash, no?
>
> Sure, such testing would be welcome, but I believe those are tested with
> our tests on most platforms.  macOS is special because it uses the last
> GPLv2 version of bash, which is less capable in some ways.  I assumed
> that bash would not be more likely to break here in newer versions, but
> perhaps I shouldn't make that assumption.

In any case, a few integration into 'pu' with the patch have been
already made e.g. https://travis-ci.org/github/git/git/builds/692290894
so we should be good ;-)

Re: [PATCH] completion: use native ZSH array pattern matching

[Junio C Hamano]

"Marco Trevisan via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: =?UTF-8?q?Marco=20Trevisan=20=28Trevi=C3=B1o=29?= <mail@3v1n0.net>
>
> When clearing the builtin operations on re-sourcing in the ZSH case we
> can use the native ${parameters} associative array keys values to get
> the currently `__gitcomp_builtin_*` operations using pattern matching
> instead of using sed.

"We can" may be a statement of fact, but by itself it does not make
a convincing argument why we should have this change in our
codebase.  

Is this change about correctness?  Is it about performance?
Or something else?

If it is about correctness, "the current code fails in this way
given this input, but with the new code the breakage is gone" would
be a good justification to give in the proposed log message.  If it
is about performance, of course a measured performance numbers would
make an objective justification that is hard to argue with,
especially if you can convince people that the patch does not change
the behaviour in any negative way.  If it is about something else,
well, there would be an appropriate way to justify the change,
depending on what it is ;-)

Thanks.