Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-workers 41914
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: GH:zsh-users/zsh-completions.
- Date: Mon, 16 Oct 2017 20:04:05 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kaLtoA h9/fiXZKxvfC8jw6sScgyefV7U+PkAS72rMnU=; b=n5QG34bYNINijHdCeFetd6 J1d7n2DsSJrdkVKPhePEXcEvzDhArdOYrqOJbKBapUvor3wb5lNRo5ER+xZ6oopn Rjwcd/+DWchN9qFUHwLR88Z7Z3bHIwbp2Cr0woakEDkY83s4GlFHFPZ0O/69kaMf uit41uLvEr7EvPwWIlsCffMb0+03P51uXxnwCjtBKOIRVvJkAiflAA5A9QWGd5TQ sQKd1TeX5vMhgxoHoLDIWC7cRu60P3RN/717JwoHPxFhXmAcwVuow/ri6sybfQIK AhSTCXDmxQbj86dfzDbbn/LRDae8KPMvj19pEa7emRa95gFnWx/SaT6f+RzIUmeQ ==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kaLtoA h9/fiXZKxvfC8jw6sScgyefV7U+PkAS72rMnU=; b=LizstA1z3H2AJa/HuEz3yJ Mn26yg6vTVGGa5CJyOAEKALOHiDeyLEtLfYwgtbgo6BstBkTjdRWEFTb1pQTIoyJ Sxc32KsemWuV+0ki3okr4XYQY7lak63xVVqtq17PqSkvTI0clHlu8/HJaxu14KOq lIOBO1VEiI2dobXBDkzNccmdZcG8ZcRrU/nhj4bMcpxMx4v9MO7WVsqTx5u+8cpv z74BMJsQN15131IATscainrsg/StTbRZUKZTNpGsrR4oOkIpOlO8PY01RvEQZJtC jTmkOUO22P4ZgBj/9D32tiYATMVNnJNhCJWRhbX1NSnK41S7OqBIKbN9SrDvE+qg ==
- In-reply-to: <firstname.lastname@example.org>
- List-help: <mailto:email@example.com>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- List-unsubscribe: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org> <CA+mcLN6ZuZ_AoKvfbceupZVg9+1btDg7NG=bGRUMDxwzLs5bcg@mail.gmail.com> <CGME20171016144130epcas1p2c1fa53d06d36c27f8ac8af3237b97721@epcas1p2.samsung.com> <email@example.com> <firstname.lastname@example.org>
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.
Messages sorted by: