From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2681 invoked from network); 20 Aug 2001 10:44:00 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Aug 2001 10:44:00 -0000 Received: (qmail 6005 invoked by alias); 20 Aug 2001 10:43:53 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15666 Received: (qmail 5992 invoked from network); 20 Aug 2001 10:43:53 -0000 From: martin.ebourne@arcordia.com Subject: Re: New options & arguments processing system for ZSH To: Felix Rosencrantz Cc: zsh-workers Date: Mon, 20 Aug 2001 11:42:47 +0100 Message-ID: X-MIMETrack: Serialize by Router on LON-ARCMTA-01/ARCORDIA(Release 5.0.3 (Intl)|21 March 2000) at 08/20/2001 11:42:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii > I think this format is complimentary to the XML stuff with which I've > been playing. I think it would be possible to generate the parse_opts > call from the XML format I'm sure that it would be possible to convert XML -> parse_opts, and if there are other tools that convert to XML from eg. man pages, I can think of some uses too. However, for most small-medium sized shell scripts I'd like to think that the format is simple enough to be coded directly. > One thing I noticed when trying to complete options to the supplied > "yes" function, was that it didn't provide much help for the options. > It provided type information, but it didn't actually tell me what the > options did. I'm not quite sure what you mean here. It does use the help text for options, so I'm going to make a couple of guesses what you might mean and try and explain a little. My appologies in advance if I'm way off track! The help text for each option/argument is extracted and stored against the option/argument. It is also made use of in both cases. For options, it is used in exactly the same way as for all the other completions I've seen, which is when you are completing the option *name* it lists the descriptions against that. When you are completing the option *value* it is not used because there is a separate description for that, which tells you the type to be completed. I have thought on occasion that it would be nice to have the option description available at the point of completing the value as well. parse_opts could be changed to do this but I think it's more of a general issue. I guess probably _arguments could do this itself, based on a style, by simply concatenating the option description onto the end of the value description. For arguments, there currently is no description of what the argument is for in any of the completions I've seen - only a description of what you are completing. I didn't want to waste the help text present in this case so parse_opts does concatenate the argument help onto the end of the value descriptions exactly as I've just suggested for options. I'm sure you're aware that various styles need to be set to be able to view the various descriptions. > The format does provide a mechanism to do that. Though > it seems like that it requires duplicating information that is already > there in the help text. So it seems if it was somehow possible to reuse > the help text already there that might be useful. Again, I'm not quite sure what you mean about specifying the help text separately. I can think of two angles: 1. Defining a type: #type newtype basetype completion_description completion_action Here you can give a full description for the value to be completed, and could duplicate the option help. As I mentioned before, I'd like to see this done in a more central place though. 2. Defining an option with helptext override: # --option * help="the description" This simply overrides the help extracted automatically from the help text. I don't envisage this will be useful except in extremely rare circumstances when it has trouble extracting help from the main text. The only reason it's there is because it's a generic method of adding new settings associated with an option/argument/type, and is also able to override all current ones. The help specified in this case will be used in exactly the way I've described above. I would like to think that there's no need for duplication of information when using parse_opts, certainly that's one of the major design goals. > This format also gives the developer a bit of control over where&how > option information is placed variables. It would be nice if _arguments > had richer control over that. Though this extra control seems like it > is more for command line parsing that for completion. Since _arguments doesn't decode values for use I don't see how that would work. Certainly this information is only used by parse_opts for the processing of the options/arguments when the command is actually invoked, not when completed. Thanks for your interest, Martin.