From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17800 invoked by alias); 10 Oct 2013 03:01:50 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31807 Received: (qmail 23568 invoked from network); 10 Oct 2013 03:01:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <131009200134.ZM3418@torch.brasslantern.com> Date: Wed, 09 Oct 2013 20:01:34 -0700 In-reply-to: <525564FE.3030705@gmail.com> Comments: In reply to Kunshan Wang "Bug: Completion of the 'zsh' command." (Oct 10, 1:15am) References: <525564FE.3030705@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Bug: Completion of the 'zsh' command. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Oct 10, 1:15am, Kunshan Wang wrote: } } 3. Type 'zsh ./h' (no quote) and press TAB } } What actually happens: The file hello.zsh is listed below, but continue } pressing TAB will not select the file 'hello.zsh'. Nothing happens. Hm. To answer your other question first: } Also there are many scripts in /usr/share/zsh/functions/Completion and } many scripts for zsh's internal commands, but there is no script for } the 'zsh' command itself. Is it placed elsewhere? Zsh and other shells are all handled by the _sh function. In general you can't tell just by the file name what commands a completion function is used for. To find this out, you can do one of two things: (1) Run "compinit" and then exampine the $_comps array, e.g. $_comps[zsh] (2) Do something similar to: egrep compdef.+zsh $^fpath/*(N.) } What I think it should happen: zsh should cycle through all filenames in } the current directory beginning with 'h' (because I typed './h') and } complete it. This does in fact work when completing for "sh" which uses the same completion function. The difference seems to be that, for zsh only, there is first a call to _arguments which has the unintended (?) side- effect of erasing compstate[insert]. The rest of completion is then tried, but with more basic functions that don't expect to need to put compstate[insert] back again, so their results are only listed and not added to the command line. I suspect _arguments really expects to be in charge of the whole process, not to be used as an adjunct to simpler defaults. There might be some different magic it's possible to apply here, but the simplest thing I can think of is to simply move the _arguments part to the end of _sh instead of doing it first. I can't find anything obvious this gets wrong, but there's always a chance that e.g. _default should have been skipped if _arguments succeeded, which this patch would break. I confess I don't understand the bit about always returning zero no matter whether _options succeeds or fails, so I've tweaked it, but maybe someone else can remember. Furthermore, I don't remember what '*:' does for _arguments; I would have expected '*:something:', and the only two places in the whole Completion/ tree where '*:' is passed to _arguments are here and in _ethtool. Someone please jog my memory? diff --git a/Completion/Unix/Command/_sh b/Completion/Unix/Command/_sh index 7258e42..59aafc2 100644 --- a/Completion/Unix/Command/_sh +++ b/Completion/Unix/Command/_sh @@ -5,10 +5,7 @@ if [[ $service == zsh ]]; then if [[ ${words[CURRENT-1]} == -o ]]; then _options # no other possibilities - return 0 - fi - if _arguments -S -s -- '*:'; then - return 0 + return fi fi @@ -25,3 +22,11 @@ else fi _default fi + +local ret=$? + +if [[ $service == zsh ]] && _arguments -S -s -- '*:'; then + ret=0 +fi + +return ret