From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1306 invoked from network); 4 May 2000 08:04:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 May 2000 08:04:04 -0000 Received: (qmail 16840 invoked by alias); 4 May 2000 08:03:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11141 Received: (qmail 16825 invoked from network); 4 May 2000 08:03:51 -0000 Date: Thu, 4 May 2000 10:03:50 +0200 (MET DST) Message-Id: <200005040803.KAA19109@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Zefram's message of Wed, 3 May 2000 16:09:00 +0100 (BST) Subject: Re: PATCH: Re: sudo completion problem Zefram wrote: > Andrej Borsenkow wrote: > >I think, it was the result of change for find (do not have article > >handy) - in ``find /tmp -user'' -user was not recognised as option > >because /tmp already was argument. So, this change made options be found > >everywhere, even after arguments :-) > > That's the wrong way to do it. In the find command line, `-user' is not > an option, it's an expression (or part thereof). The expression starts > with the first argument that starts with `-' and continues to the end > of the line; the directory arguments must appear before the expression. > Actual options are handled as dummy predicates, which is confusing to > the user, but from our point of view means that they must be treated as > part of the expression. > > find has a unique syntax, with no options having the usual option syntax. > Therefore it shouldn't be handled by the standard option completion > function; it needs a dedicated find-expression completion function. I don't think we really need this. Especially since it works quite well for most cases where one would want to complete. We could change _find to complete normal arguments with a `->foo' action and there decide if directories or only \!, \( and \) should be completed (depending on there being an `opion' on the line or not). In that case it should do the right thing in every case even if the -* things aren't really options. > The standard option completion function should, as is standard syntax, > process options only before the first non-option argument. It's a simple `(-)' for the first argument and allows us to use _arguments both for things like _find *and* for commands with options after sub-commands (cvs, etc.) and with commands whose command lines can consist of multiple option/argument pairs (like zrecompile or some such). This flexibility is certainly a big win, as I hope you'll agree. Andrej Borsenkow wrote: > ... > > This may be useful in other cases as well. cvs comes in mind > immediately - common options, then checkout, update, etc as argument - > and possibly (sub-)options and (sub-)arguments for every of them. Sub-commands (and their options and arguments!) as arguments to every(!) common option? What's wrong with the way _cvs works now? > I understand, that this is hierarchical structure that probably cannot > be handled with one single table ... but, just as idea, imagine that > action for `update' argument simply points to subarguments description > ... or something like this ... this may be more readable than shell > functions. May be not. But it is easier in cases, where we need several > versions for different plattforms. For the different-platform problem: the easiest and most readable way is still and will ever be: a `case ... in ... esac'. Either setting up an array of _arguments-specifications or calling _arguments directly. > Then I realised, that reverse situation exists with options - there is > no way to describe options without - prefix. Consider dd or tar ("tar" > not "GNU tar" :-), BSD ps ... In case of dd we have only options; in > case of tar ot ps, the first word consists of single letter options with > possible arguments in next words in order. There is no way to describe > both case with _arguments (unless I'm mistaken). I *really* don't think we should make _arguments do this. I know _arguments is handy in many cases but it should *not* be the only function used if that requires to make it more complicated than compctl ever was. The main reason for inventing the new completion system was to get at the flexibility of shell functions, after all. If we want to give help completing certain kinds of things we should write new utility functions that can be combined with existing functions or we should write wrappers around existing functions (like _argument_sets). But we shouldn't put everything into one basket. > And I'd like repeat once more - currently, when _arguments is using > lexical structure to describe semantic, it is hard to add something. If > we had flags ... (not suggesting breaking compatibility - but just for > future use). I don't know what you are alluding to here. When did you complain about it? And to make me believe that flags would help here I need 1) a more complete description of how the flags work and 2) examples where currently `it is hard to add something'. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de