zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: zsh virsh completion
Date: Mon, 11 Jul 2016 09:40:30 -0700	[thread overview]
Message-ID: <160711094030.ZM13696@torch.brasslantern.com> (raw)
In-Reply-To: <8eb6dce0-50d7-5ab2-503a-194c1de2e45d@redhat.com>

On Jul 11,  2:52pm, Marko Myllynen wrote:
}
} - virsh help <command> 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 ?)


  parent reply	other threads:[~2016-07-11 16:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 11:52 Marko Myllynen
2016-07-11 15:03 ` Roman Neuhauser
2016-07-11 16:40 ` Bart Schaefer [this message]
2016-07-11 22:07 ` Oliver Kiddle
2016-07-12 10:23   ` Marko Myllynen
2016-07-13  4:59 ` Daniel Shahaf
2016-07-18 12:06   ` Marko Myllynen
2016-07-20  6:58     ` [PATCH] _virsh (Was: Re: zsh virsh completion) Daniel Shahaf
2016-07-20  8:36       ` Marko Myllynen
2016-07-21  6:57         ` Daniel Shahaf
2016-07-21 12:32           ` Marko Myllynen
2016-07-22  6:30             ` Daniel Shahaf
2016-07-22  8:17               ` Marko Myllynen
2016-07-21 16:12         ` Oliver Kiddle
2016-07-21 16:19           ` Marko Myllynen
2016-07-22  7:19           ` Daniel Shahaf
2016-08-31 21:15             ` Oliver Kiddle
2016-09-02  5:23               ` Daniel Shahaf
2016-09-02 15:02                 ` Oliver Kiddle
2016-09-04  4:01                   ` Daniel Shahaf
2016-09-07  6:39                     ` Bart Schaefer
2016-09-09 22:09                       ` Oliver Kiddle
2016-09-11  9:08                         ` Daniel Shahaf
2016-09-14 23:19                     ` Oliver Kiddle
2016-09-04 21:24                   ` Daniel Shahaf

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=160711094030.ZM13696@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /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).