From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19986 invoked by alias); 11 Jul 2016 16:40:15 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38827 Received: (qmail 6009 invoked from network); 11 Jul 2016 16:40:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=zctEjfTjDPMZUBwHvDFm8UIcfoOgvNTkG23FD44anW0=; b=wG71C+VGV+lQ0j26uGmYjqkAAyWFi8/dHcXlGFxQX9q7JThQw+VLlDwUgNmH3lZVLS gCXRAcltujZL3brY+S7BIX2uVAaRCKZbucZU+NUKdwxQb3ZO0CC3SBfoXW9rWud4MO/F Blz7Qqbc+I4Ai2NkJTDYykB6CFyx+UM4ECbG9kx0AIHC55O+TcfeCXjKwB4kxD0VIg8s 3S4bvpjZe83WJlzqUNQTTU4FpPeM4cDTJIAGs8LSAFWttNR+O28fC+k/TkrP3Bc8nVAV RzGyx4teRCfgmJotYQFiEn4c04z8MQhJ9cz7rHQ2Un58ffiZ7Pub8BRPrTDTSYY7ZwNl IFcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=zctEjfTjDPMZUBwHvDFm8UIcfoOgvNTkG23FD44anW0=; b=WNUMqyVZGC7QsQ0P7w30PQ8FGy+lv2ew1zX5GlS7G9lzIN44XFuinCgAF466/12f0I JYZc6DGVwnASTL2AqLBnNQLY0fD8/GEkAl54UNznxundRSk2e/q3vW0jKh30NGSvSi1B Aw7kdX1JEW6X7LphHeqNJISs7/GBLMPI8Y5KJ6460aA/RyBlTkJ8ujQfeFiHcl1TyJPk CY/lUyAnNxKj99fH7wVCuicojxN3HczEmgKYegGxcEeZDVAovFKIShQB1bzuK+Jg4t7/ d9DmXS8HNxLQxVq01lTTQFHkeaZDXLSFqACfkFgrJDJbUlbgIPuXhNQyhn7DnLfg6dd8 c6nQ== X-Gm-Message-State: ALyK8tIJFz6CEl1srd/Nl5Tiy2Zg//eHHtQcTXmD/+WHQYRv7VOqg7Yxqa1WSmcE2oFyug== X-Received: by 10.98.9.141 with SMTP id 13mr36911851pfj.130.1468255212007; Mon, 11 Jul 2016 09:40:12 -0700 (PDT) From: Bart Schaefer Message-Id: <160711094030.ZM13696@torch.brasslantern.com> Date: Mon, 11 Jul 2016 09:40:30 -0700 In-Reply-To: <8eb6dce0-50d7-5ab2-503a-194c1de2e45d@redhat.com> Comments: In reply to Marko Myllynen "zsh virsh completion" (Jul 11, 2:52pm) References: <8eb6dce0-50d7-5ab2-503a-194c1de2e45d@redhat.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: zsh virsh completion MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 11, 2:52pm, Marko Myllynen wrote: } } - virsh help output is pretty much like --help output of any } other program, is there a trick to make the option descriptions also } available when completing virsh command options? I think you're asking about the call to _values in the cmdopts state handler. Each of the option specs (the words that you're caching in _cache_virsh_cmdopts) can be in the form "-option[description]" just like an option spec for _arguments. So you would need to parse the output of $(virsh help $cmd) a little more deeply than you presently do to build those strings, and then do something a bit more clever than ${=_cache_virsh_cmdopts} to cache and split them. There is support in _arguments for parsing --help formatted output. The basic pattern for having _arguments do this when "virsh --help" doesn't produce that output, is to add a "command" style similar to: zstyle :completion::complete:virsh::options command 'virsh help' The exact zstyle context to use depends on how you're making the call to _arguments. For your virsh completer you would need another call to _arguments in the cmdopts state handler and corresponding change to the context. This can be tricky to get right. } - would it make sense (or is it perhaps already possible somehow) to } optionally enable "best guess" completion for all commands which have } no command specific completion rules available yet? There are lots of } commands for which completing just the options captured from --help } output would already be hugely helpful. I think you're looking for compdef -P '*' _gnu_generic Which just says to try GNU-style options after all else fails, no matter what the command word might be. However, here's presently no way to make sure this is called after other "compdef -P" patterns that may be more specific. (This leads me to wonder whether all those "#compdef -P" lines in Completion/** files ought to instead be "#compdef -p". I guess the point is to allow the user to override with other compdefs and try the supplied completions if none such is present? But in that case shouldn't _init_d also use -P rather than -p ?)