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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org