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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list