From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9359 invoked from network); 8 Feb 2002 09:41:02 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 8 Feb 2002 09:41:02 -0000 Received: (qmail 5951 invoked by alias); 8 Feb 2002 09:40:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16592 Received: (qmail 5940 invoked from network); 8 Feb 2002 09:40:54 -0000 Message-ID: <20020208094052.89650.qmail@web9307.mail.yahoo.com> Date: Fri, 8 Feb 2002 09:40:52 +0000 (GMT) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: ssh completion problem To: Bart Schaefer Cc: zsh-workers@sunsite.dk In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bart wrote: > > Right again, so far ... however, in looking at my own _complete_debug > output *before* applying your patch, the odd thing is that the first > compadd is failing for no apparent reason. That is, for completion after > `lll@', it does `tmp=(bbb.com)' and `compadd -F _comp_ignore -a tmp', > but even though bbb.com is not ignored, still the compadd returns 1. I can't reproduce that. > > I think the patch below is the right fix - provided tmp can't be > > This doesn't work as I want. With the patch, the values from users-hosts > become the only possible matches, so I can't complete other hostnames. Ah sorry, testing $#tmp was basically wrong. The correct nasty hack would be to use compadd -O thusly: - compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" } + (( i=argv[(i)-F] )) + compadd -O all "${(@)argv[1,i]}" "${(@)argv[i+2,-1]}" -a tmp + if (( $#all )); then + compadd "$@" -a tmp + elif (( $+functions[_$key] )); then + "_$key" "$@" + fi This is working around what I think is a fundamental problem with nested tag loops where an outer loop splits tags into labels: Suppose that an outer tag loop separately completes several labels for a tag and that there is an inner tag loop for which there is a defined tag-order. It can't then be known in the inner loop if matches are added for a tag because it might be ignoring matches for a different label which are added after it back-tracks to the outer tags loop and then down to the inner loop with a new tag label. Without this knowledge, the inner loop can't know whether to allow tags which appear later in the tag-order to be completed. Using a tags loop in _combination runs in to problems with this. The following patch appears to work: -local sep tag style keys pats key num tmp +local sep tag style keys pats key num tmp expl i all ret=1 + _my_accounts() { + _wanted hosts expl host compadd "$@" -a tmp + } - compadd "$@" -a tmp || { (( $+functions[_$key] )) && "_$key" "$@" } + _tags "$tag" "not-$tag" + while _tags; do + (( $+functions[_$key] )) && + _requested "not-$tag" expl 'ignore' "_$key" "$@" && ret=0 + _requested "$tag" expl '' _my_accounts "$@" && ret=0 + (( ret )) || break + done More by luck than judgement however as looking up the tag-order with the my-accounts tag is clearing _comp_ignore. The little _my_accounts function is then needed so that we get one last _next_label loop to separate the hosts out again. Only dividing tags into labels before compadds might be a way to solve this. I need to investigate further because I don't fully understand how tags and labels work. I may have badly misunderstood things so far. Sven? This is unrelated but out of interest, why is the _next_labels stage skipped in some completion functions? Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com