From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2879 invoked from network); 4 May 2000 12:01:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 May 2000 12:01:21 -0000 Received: (qmail 20605 invoked by alias); 4 May 2000 12:01:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11149 Received: (qmail 20546 invoked from network); 4 May 2000 12:01:01 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: Re: sudo completion problem References: <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII From: Tanaka Akira Date: 04 May 2000 21:02:06 +0900 In-Reply-To: <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru> (Andrej Borsenkow's message of "Thu, 4 May 2000 11:23:36 +0400") Message-ID: User-Agent: T-gnus/6.14.1 (based on Gnus v5.8.3) (revision 16) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.6 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN) In article <000601bfb599$a9219f80$21c9ca95@mow.siemens.ru>, "Andrej Borsenkow" writes: > So, the question is - how useful would it be to allow "named, > structured, ..." arguments? The point is, description vs. shell code. > Basically, be able to treat arguments in almost the same way as > options - with some separator in between. In this case, we could still > use _arguments for find - actually, it does it quite well currently, and > it is a pity to reinvent the wheel. Although I think (-) is good extension, I agree that there are commands which has too complex argument parsing routine to handle by _arguments. And it is true that writing dedicated handling routine as shell function is too difficult in general. We need intermediate solution for a completion function of such commands: more powerful than _arguments and easier than shell function. But more difficult than _arguments, maybe. My idea is already implemented: _regex_arguments. Although currently there are only three completion functions - _apt, _xwit and _xset - which use _regex_arguments because it cannot use _arguments, I think there are more completion functions which can be written bit more simple if _regex_arguments is used. Maybe, _xauth (and _cvs?). > 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. In _regex_arguments, a arguments of commands are described as regex like notation. Of course, it can handle hierarchical one. > 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). _regex_arguments doesn't handle `-' or `+' specially. > 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). _regex_arguments handle only parsing of arguments. So other stuff handled by _arguments such as descriptions, exclusive options must be implemented by completion function writer. It's bit hard task but we can implement special feature easily. -- Tanaka Akira