Re: GH:zsh-users/zsh-completions.

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote on Mon, 16 Oct 2017 16:11 +0100:
> That seems to me the wrong way to go.  There's no absolute need for
> completions to be in the same place as the source.

I think, in the long term, completions should be generated by option
parsing libraries (getopt(3), optparse, GetOpt::Long, etc).  The way I
see it is:

- Option parsing libraries compile the --options specification --- which
  they already have --- into a format usable by the shells.  That format
  is an API exposed by the shells.

- That format could be either "autoloadable functions to be run by
  compsys" or possibly a shell-agnostic format, that bash and zsh both
  know how to parse.

- The information could be made available to the shells either as a static
  file at a well-known path (compare /usr/share/pkg-config/foo-1.pc) or
  as the dynamic output of a standardly-named "foo --parseable-help"
  flag.  The former has the advantage that it's automatically
  detectable; the latter would require <handwave/> for the shells to
  know that a particular command supports that flag.  (to avoid the
  "`hostname --help` on solaris" thing)

Then completions would be automatically up to date, but on the flip side
it'd be harder to implement a sweeping change across all completions in
the world: we'd have to collaborate with the various option parsing
libraries on getting new compsys features exercised.  (And with bash
too, if the interchange format is shell-agnostic)

That's my blue sky.  It won't eliminate all code in Completions/ ---
functions such as _git would still have a reason to exist --- but it'd
eliminate the tedious work of copying --help output, downcasing the
first letter of every line, and doing that again after a new release of
the program being completed.

Sorry for the brain dump.

Daniel