From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11560 invoked from network); 19 Apr 2001 14:02:03 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 19 Apr 2001 14:02:03 -0000 Received: (qmail 12114 invoked by alias); 19 Apr 2001 14:01:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14031 Received: (qmail 12101 invoked from network); 19 Apr 2001 14:01:55 -0000 Sender: kiddleo Message-ID: <3ADEEFCC.E3D1C6ED@u.genie.co.uk> Date: Thu, 19 Apr 2001 15:01:48 +0100 From: Oliver Kiddle X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.15 i686) X-Accept-Language: en MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: problem with _arguments exclusion lists References: <200104171410.QAA08041@beta.informatik.hu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sven Wischnowsky wrote: > > ;-) I understood you, really. But I'm pretty sure there are programs > that allow other (single letter) options after that `-c', meaning that > either `-c's argument is the empty string or that it comes in the next > word. Or something. So I still think we need a way to tell _arguments > that either: > > 1) after all `-x-:...' or `-x+:...' options other options may be > completed, or I suppose this option would involve another option to _arguments like -W and it would only be useful with -s. > 2) that after some of those options other options may be completed, or And, I suppose this would handle commands which are inconsistent in the way they behave for different options. For the _arguments syntax, I can't think of much better than some additional random character before the colon. I suppose that of these (2) covers more possible situations so is the most complete but we could have both where the option (as per (1)) specifies a default and the syntax for (2) overrides it. Keeping this in mind, if (1) is implemented, (2) could be added later if we find inconsistent commands for which it is needed. > All that is independent of what we choose to use as the default. I.e., > if we leave the current behaviour the default or if we make completing > options there the default (unless otherwise specified). I would probably vote for the current behaviour being the default - that is not completing other options in this case because it is probably more common for commands to parse arguments that way and it keeps the number of matches down. > Or maybe I'm thinking way to complicated again and we should just make > it try completing options in such places, too. If the user has already Possibly, but I would err on the side of making it not try completing options in such places. When I type commands, I tend to specify them in a clear sensible way rather than the most minimal way that command happens to allow. > started typing the argument of the option, other option names won't > match anyway. True. And if other option names do match, the user might be trying to complete the option name so it is important that it is added as a match. > Leaves only the slight ugliness that `-c' would > offer other single-letter options as possible completions (if _arguments > was given the -s options), even if the command doesn't allow that after > options that get an argument. That is really quite ugly and backs up my feeling that this should not be the default. > 3) (what you described) that the argument of option `-x+:...' has to > match a certain pattern and if it doesn't match, other options are to > be completed there. I think it is a good idea to maybe complete options only if we fail to complete the option argument because it avoids the ugliness mentioned above. Would it be possible to use a tag-order style to put the options last here? I wouldn't want to put the pattern in _arguments though. What follows is a separate issue really so is a bit of a divergence. As a test, I created an _number like this: [[ $PREFIX$SUFFIX = [0-9]# ]] || return 1 _message 'number' && return 0 And then used this _arguments: _arguments -s '-c+:number:_number' '-conf' Now, if I complete after -co, I get the message: No matches for: `number' or `corrections' What _arguments should do in this case is see the return code from _number and from it conclude that we are not completing a parameter to -c because it failed. For (3), it could then complete other single letter options (it should be adding -conf as a match regardless). This may be more complicated but is how I think we should be specifying patterns if we use option (3). Incidentally, with this when completing after just -c, the message `number' is displayed to indicate that what is expected is a number. It does not look up the format style with the descriptions tag and display it in bold (with my style settings). I think it should because `number' is a group of matches the same as other things we complete (option, user etc), it is just that we haven't generated as matches all possible numbers. We could have a general function which is called like _message to say we are completing such and such sort of thing but are not adding the actual matches because it doesn't make sense to. It could take an option for specifying a pattern to compare against $PREFIX/$SUFFIX to allow it to fail when appropriate. Oliver