Auto-created completion.

Auto-created completion.

[Rodger Anderson]

Since folks are talking about what a future zsh might have, here is my
idea:

Zsh would be able to automatically figure out what each program might
need for options/arguments and do completion accordingly.

This would require that every program have some way to tell zsh what
its options are, so this idea is pretty far-fetched.

GNU programs have the --help option.  The output format of "find
--help" is meant to be viewed by a person, not parsed by a program, so
perhaps if there were a --synopsis option or something.

The first time a zsh user runs the "find" program, zsh would run "find
--sysopsis" and parse the output to create a completion map for that
command and cache the results.

Auto-created completion.

Rodger Anderson

Re: Auto-created completion.

[Tim Pickett]

> Zsh would be able to automatically figure out what each program might
> need for options/arguments and do completion accordingly.
> This would require that every program have some way to tell zsh what
> its options are, so this idea is pretty far-fetched.

This would involve a lot of cooperation on the part of developers.  You
certainly couldn't expect all programs to support this for all the
different completion standards (it'd need to check the $SHELL variable
to determine the type of shell and print the corresponding
compctl-oe-equivalent for that shell). 

You might be able to get
programs which accept GNU options to agree on a standard, say,
--complete, which would do this.  Then in your shell you can say 'eval
`program --complete`' to add to the shell's compctl list.  For a bit of
syntactic sugar you yould have zsh do something like 'compctl -V
program' (or some other letter not yet used) which does this and marks
the completion as autoloadable so the eval is only done when needed.  On
the plus side this might speed up zsh startup, which for me is pretty
slow given my 100 compctls.  (Which brings up another point - even if we
can't have programs supply their own compctls, autoloadable compctls
might be a good idea in itself.)

On another level, people expect different things from completion.  My
GNU ls compctl looks like this:

-f -x "s[--format]" -k "(long verbose commas horizontal across vertical single-column)" -P "=" - "s[--sort]" -k "(none time size extension)" -P "=" - "s[--time]" -k "(atime ctime access use status)" -P "=" - "s[--width=][--tabsize=][--ignore=][-w][-T][-I] , c[-1,-w][-1,-T][-1,-I]" -k "( )" - "s[--]" -k "(all\  escape\  directory\  inode\  kilobytes\  numeric-uid-gid\  no-group\  hide-control-chars\  reverse\  size\  width= tabsize= almost-all\  ignore-backups\  classify\  file-type\  full-time\  ignore= dereference\  literal\  quote-name\  no-color\  7bit\  8bit\  recursive\  sort= format= time= help\  version\ )" -S "" - "s[-]" -k "(a b c d f g i k l m n o p q r s t u x A B C F G L N Q R S U X 1 w T I)" 

But other people might be content with (indeed, prefer) something like:

ls -f

Which should ls provide?  For that matter, zsh has undergone several
changes.  Notably the -K option is relatively new.  Should programs
check the VERSION shell variable too and attempt to provide the right
compctl string for each version?

What might be more feasible is simply to have archives of compctl
and have people download them if they want and have them autoloaded as
needed.

-- 
Tim Pickett                                     tlm@yoyo.cc.monash.edu.au
"Oh, Caesar, emperor of Rome. [zzzt]"          tbp@molly.cs.monash.edu.au