From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 883 invoked from network); 28 Apr 2000 12:14:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Apr 2000 12:14:47 -0000 Received: (qmail 1970 invoked by alias); 28 Apr 2000 12:14:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11006 Received: (qmail 1938 invoked from network); 28 Apr 2000 12:14:36 -0000 Date: Fri, 28 Apr 2000 14:14:34 +0200 (MET DST) Message-Id: <200004281214.OAA20191@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Fri, 28 Apr 2000 12:56:24 +0100 Subject: Re: (file) completion in compinstall Peter Stephenson wrote: > > As I understand, compinstall is using vared to get input. Currently, > > completion in the first prompt (for the file name) tries to complete > > commands; I did not try any other (is there anything accept file names > > that may be sensibly completed? I believe, everything else is menu > > driven or free text input) > > I was going to remark on this, too, but forgot. As far as I know, > completion usually just treats a line of vared input exactly the same way > as an ordinary command line. This is very rarely the most useful > behaviour; a better default would be ordinary default completion, > i.e. assume a null command and treat the rest as command words. > > There's some low-level support: compstate[vared] gets set to the name of > the parameter being edited and can be detected in completion functions. > However, there doesn't seem to be any support in the function system with > the exception of some commented-out code in _first, which would treat the > line being edited as if you were editing an assignment to that variable. I > can't remember why that's not the default. Now that you say that... neither can I. > It might be possible to change this in compinstall by setting > compstate[context] directly, but come to think of it, I doubt if it > actually is possible outside a completion widget. Even then, making the > value local would be unpleasant. You can't, $compstate is not available there. > I'd prefer a more general solution to completion with vared, if Sven has > any ideas... That's what $compcontext is for. Similar to what Functions/Misc/nslookup does, you just do: local compcontext=compinstall And then have a completion function with `#compdef compinstall'. There you either unconditionally complete for inside of compinstall or, like _nslookup, you first test `[[ -n "$compcontext" ]]' to see if you are completing inside compinstall or its arguments. Using the indirection ($compcontext gives a context which is looked up in $_comps) allows users to override the default implementation with their own functions, as usual. Is that enough and clean enough? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de