On 06/27/2011 12:06 PM, Michal Privoznik wrote:
> That is, if you have command-based custom generators, then each
command
> has to repeat parsing functionality, then call back to common list
> generators; whereas if you have option-based custom generators, then you
> have fewer callbacks because all the smarts are tied to well-typed
> options, and after all, it is the type of each option that determines
> which list to generate, more than the type of the command that includes
> the option.
>
I was thinking about same feature and started to work on it during this
weekend. But I ran into a problem. Basically, what I intended to
implement, is:
1.) expand struct vshCmdDef for a char *(*callback) (const char *text,
int state). But for real benefit, we need connection object, so we could
e.g. list only inactive networks for 'net-start' command. And this is
the problem, because we would have to make this object global (since
readline functions does not allow passing any opaque value).
As gross as it is, a global object isn't entirely bad - virsh is
single-threaded. And even if we want to make virsh threaded at some
point, I still think we can get away with adding a thread-local access
scheme.
2.) expand each command definition with its own completer. So e.g. for
start commands we could only list inactive domains, networks, pools,
whatever. For destroy only active objects. And so on.
So maybe we want both - an option-based completer that generates the
initial list, and a command-based completer that can then prune out
irrelevant options?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org