From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7077 invoked from network); 20 Apr 2001 08:31:47 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Apr 2001 08:31:47 -0000 Received: (qmail 18274 invoked by alias); 20 Apr 2001 08:31:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14052 Received: (qmail 18263 invoked from network); 20 Apr 2001 08:31:39 -0000 From: Sven Wischnowsky Date: Fri, 20 Apr 2001 10:31:34 +0200 (MET DST) Message-Id: <200104200831.KAA14053@beta.informatik.hu-berlin.de> To: zsh-workers@sunsite.dk Subject: Re: problem with _arguments exclusion lists In-Reply-To: <3ADEEFCC.E3D1C6ED@u.genie.co.uk> Let me try to summarise: 1) Add an option to _arguments, that says that it should always try to complete options after options specified with `-x-:...' or `-x+:...'. This makes it a stronger form of -W: -W makes it complete options after options that get an argument in the next word. The new option says that other options are to be completed even if the argument has to or may be given in the same word. 2) Also, make it try completing options in those places even if the new _arguments-option is not given but the action for the argument returns non-null. The `returns non-null' is, of course, problematic again if the option- argument has to be completed with a `->state' action. But I think if a command is complicated enough to require that, it should use the option from 1) anyway. And add a small utility function that can be put into an argument- action and tests if the string typed so far matches some pattern. For simplicity I would make it use the description given in the _arguments-spec. And if a simple pattern match is enough for most cases, this makes it sound as if we should just add a new action- syntax, avoiding the need for an extra function consisting of only two lines. More complicated tests can still be implemented with additional functions, of course. I don't remember exactly, but I think we were talking about pattern matching in _arguments-actions some time ago. If we decide to put the simple matching-case into _arguments itself, we could also go another way: instead of making it a new type of action, we make it be some kind of `guard' that can be prefixed to any of the action-types _arguments supports now. If it is given before an empty option, it only says if a message should be displayed or not. I think I like this even better. Ok, would this be enough for now? Later we can, as suggested by Oliver, add a way to change the behaviour on a per-option basis, using the option from 1) as the default. If we ever meet a command that needs that much control. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de