zsh-workers
 help / color / mirror / code / Atom feed
From: Felix Rosencrantz <f_rosencrantz@yahoo.com>
To: zsh-workers <zsh-workers@sunsite.auc.dk>
Subject: Generating completion functions from XML
Date: Wed, 18 Jul 2001 18:52:54 -0700 (PDT)	[thread overview]
Message-ID: <20010719015254.32691.qmail@web10401.mail.yahoo.com> (raw)

Recently there was discussion about how it is harder to create new      
completion functions under the new completion system than the old.      
The new system is easier to use as installed, since there are so many   
great completion functions available, and those do a much better job at 
completion than anything before.                                        

Part of the problem is the new system provides much more functionality. 
To do a good job, it takes more than just listing the flags to          
_arguments, now there is help to provide for the each flag, and then    
help for the flag value.  There are more options on what flags are      
exclusive and equivalent, and many times this information has to be     
repeated.                                                               

It still has been bothering me that it is not easier to create new      
completions.  I've thought about writing shell/perl/python/* scripts    
that could attempt to make good guesses based on usage information or   
man pages, and generate the appropriate _arguments call. (_arguments    
can already do this at runtime with GNU getopts like output.)           

But I suspect any scripts would still hit some sort of 90/10 rule.      
It'll get you 90% of the way but there will still be the final 10%      
which will have to be done manually.                                    

So I feared having to look at partially wrong _arguments calls.  That   
command has a lot of syntactic sugar and there is more on the way (e.g. 
recent changes).  It's not easy for me to remember what each special    
character and grouping does.                                            

It occurred to me that having an intermediate file format would be a    
good idea.  Possibly something that would be a little more descriptive, 
maybe even interspersed with comments and documentation (both from      
zsh & the command).  Also it should be easier to edit.  Also, it        
should make it easier to specify commands that have subcommands (e.g.   
cvs).  There would need to be a tool which transform this intermediate  
file format into the appropriate completion function, generating the    
appropriate call to _arguments, _values, etc.  Also, as the syntax to   
_arguments changed it would be possible to change this generation tool, 
and then regenerate the completion function.  Maybe even _arguments     
could even take this intermediate format file as input.                 

To me it seemed like XML would be a good format to use for this         
intermediate format.  The XML format could be designed with the idea    
that is it meant more for a person to understand, and edit.             

Some things that would then be possible.  It would be possible to write 
code that inserts standard documentation describing how zsh works (e.g. 
how does it handle exclusive flags or equivalent flags) right next to   
the place where the command specific information is being provided.     
Command specific help (such as pulled from the man page) could be       
embedded in the XML.  It would also be possible to embed zsh source     
code for flags that use $state in the XML.                              

It would be possible to provide zstyle information (e.g. default        
values, values to look up) for particular arguments.  Also, editing     
this file would provide another point of customization.                 

I don't think the XML format devised would necessarily have to be able  
to generate completion functions for every possible command.  Just have 
to be good enough to work for a good portion of commands.               

So I've gone on long enough about this.  Does this sound like something 
that could provide an additional easier to use interface to the         
completion system?                                                     

-FR.


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/


             reply	other threads:[~2001-07-19  1:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-19  1:52 Felix Rosencrantz [this message]
2001-07-19  8:56 ` Sven Wischnowsky
2001-07-19 15:48   ` Bart Schaefer
2001-07-19 18:42     ` Adam Spiers
2001-07-21  1:16 Felix Rosencrantz
2001-07-21 13:54 ` Oliver Kiddle
2001-07-22 20:34   ` Felix Rosencrantz
2001-07-23  4:25     ` Andrej Borsenkow
2001-07-23 10:56       ` Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010719015254.32691.qmail@web10401.mail.yahoo.com \
    --to=f_rosencrantz@yahoo.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).