Getting original words after _arguments

Getting original words after _arguments

[Felipe Contreras]

Hi,

I have a function along these lines:

__test ()
{
	local curcontext="$curcontext" state state_descr line
	typeset -A opt_args
	local -a orig_words

	orig_words=( ${words[@]} )

	_arguments -C '--stuff' && _ret=0

	words=( ${orig_words[@]} )

	# stuff using words
}

I need to have access to the original array of words, before the
_arguments stuff is run, and so far the only I can achieve that is by
manually storing the old ones, and then restoring them.

Is there an easier way? Surely the contents of the command line must
be stored somewhere.

Cheers.

P.S. Please reply-to-all so I stay in the loop.

-- 
Felipe Contreras

Re: Getting original words after _arguments

[Bart Schaefer]

On Apr 19,  3:21am, Felipe Contreras wrote:
}
} 	orig_words=( ${words[@]} )
} 	_arguments -C '--stuff' && _ret=0
} 	words=( ${orig_words[@]} )
} 
} I need to have access to the original array of words, before the
} _arguments stuff is run, and so far the only I can achieve that is by
} manually storing the old ones, and then restoring them.

Hmm. The variable named "words" is special to the completion system, and
if _arguments modifies it that probably means that later stuff is going
to depend on the state in which $words was left.  You may confuse things
by stuffing $orig_words back into words.

Is there some reason you can't just work on orig_words in the rest of
your function?
 
} Is there an easier way? Surely the contents of the command line must
} be stored somewhere.

If you literally want the contents of the command line, a completion
widget is still a widget, so you can examine $BUFFER et al.  I'm not
sure this is "easier" than copying the original state ...

Re: Getting original words after _arguments

[Peter Stephenson]

On Sat, 20 Apr 2013 08:36:34 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 19,  3:21am, Felipe Contreras wrote:
> }
> } 	orig_words=( ${words[@]} )
> } 	_arguments -C '--stuff' && _ret=0
> } 	words=( ${orig_words[@]} )
> } 
> } I need to have access to the original array of words, before the
> } _arguments stuff is run, and so far the only I can achieve that is by
> } manually storing the old ones, and then restoring them.
> 
> Hmm. The variable named "words" is special to the completion system, and
> if _arguments modifies it that probably means that later stuff is going
> to depend on the state in which $words was left.  You may confuse things
> by stuffing $orig_words back into words.

This has just reminded me that one special aspect of "words" is that it
gets restored after the current function exits.  So if it's feasible to
do the additional thing you want in a separate completion function --- I
have a feeling even the caller would be good enough, so even a trivial
function to nest the call to _arguments --- that's one way out.
(_arguments changes the value of "compstate[restore]", which is why the
altered value of "words" propagates back from it.)

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: Getting original words after _arguments

[Felipe Contreras]

On Sat, Apr 20, 2013 at 10:36 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Apr 19,  3:21am, Felipe Contreras wrote:
> }
> }       orig_words=( ${words[@]} )
> }       _arguments -C '--stuff' && _ret=0
> }       words=( ${orig_words[@]} )
> }
> } I need to have access to the original array of words, before the
> } _arguments stuff is run, and so far the only I can achieve that is by
> } manually storing the old ones, and then restoring them.
>
> Hmm. The variable named "words" is special to the completion system, and
> if _arguments modifies it that probably means that later stuff is going
> to depend on the state in which $words was left.  You may confuse things
> by stuffing $orig_words back into words.

I know, I'm not going to usw zsh completion after that point.

> Is there some reason you can't just work on orig_words in the rest of
> your function?

It's not my code, it's git.git's bash completion, which uses 'word'.

> } Is there an easier way? Surely the contents of the command line must
> } be stored somewhere.
>
> If you literally want the contents of the command line, a completion
> widget is still a widget, so you can examine $BUFFER et al.  I'm not
> sure this is "easier" than copying the original state ...

Maybe not.

-- 
Felipe Contreras

Re: Getting original words after _arguments

[Bart Schaefer]

On Apr 20,  5:03pm, Felipe Contreras wrote:
}
} > Hmm. The variable named "words" is special to the completion system, and
} > if _arguments modifies it that probably means that later stuff is going
} > to depend on the state in which $words was left.  You may confuse things
} > by stuffing $orig_words back into words.
} 
} I know, I'm not going to usw zsh completion after that point.

I'm sure you aren't, but the mix of user-function and built-in code in
the completion system means that there may be side-effects propagating
up to the caller of your function.  I'm probably being overly paranoid.
 
} > Is there some reason you can't just work on orig_words in the rest of
} > your function?
} 
} It's not my code, it's git.git's bash completion, which uses 'word'.

Aha.  So you're using bashcompinit?  If not, you might want to look at
the _bash_complete function from there.  Also, if there's a shortcoming
in zsh's git completion which is forcing you to use the one from bash, I
think there are a few people on this list who might want details.

Re: Getting original words after _arguments

[Felipe Contreras]

On Sun, Apr 21, 2013 at 1:55 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Apr 20,  5:03pm, Felipe Contreras wrote:
> }
> } > Hmm. The variable named "words" is special to the completion system, and
> } > if _arguments modifies it that probably means that later stuff is going
> } > to depend on the state in which $words was left.  You may confuse things
> } > by stuffing $orig_words back into words.
> }
> } I know, I'm not going to usw zsh completion after that point.
>
> I'm sure you aren't, but the mix of user-function and built-in code in
> the completion system means that there may be side-effects propagating
> up to the caller of your function.  I'm probably being overly paranoid.

Yes you are. I know what the possible side-effects are, and I am
knowingly avoiding them, it works perfectly fine, it's just not neat.

> } > Is there some reason you can't just work on orig_words in the rest of
> } > your function?
> }
> } It's not my code, it's git.git's bash completion, which uses 'word'.
>
> Aha.  So you're using bashcompinit?

No I'm not.

> If not, you might want to look at
> the _bash_complete function from there.

I have, I've helped to write it. In fact, I'm probably the main
contributor at this point. In fact, I'm aware of at least one bug for
which I haven't managed to send the patch for.

> Also, if there's a shortcoming
> in zsh's git completion which is forcing you to use the one from bash, I
> think there are a few people on this list who might want details.

I already discussed the shortcomings in this list:
http://thread.gmane.org/gmane.comp.shells.zsh.devel/22454/focus=22475

Basically it's dead slow, and Nikolai Weibull is opposed to make it usable.

BTW. My zsh wrapper for git.git bash's completion is the official way
git recommends completion for zsh, and it's distributed accordingly:
https://git.kernel.org/cgit/git/git.git/tree/contrib/completion/git-completion.zsh

And the folks of 'oh-my-zsh' are also thrilled of finally having
completion that is not slow as a snail:
https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/gitfast

Cheers.

-- 
Felipe Contreras