Re: [libvirt] [PATCH] virsh: add custom readline generator

On 06/28/2011 05:29 PM, Michal Privoznik wrote: > On 27.06.2011 21:39, Eric Blake wrote: >> 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? >> > > Well, I would say that is the highest goal to be achieved. Although that > implies parsing during options generation. > > But I don't think I get it. Option-based completer generates list for > given option, command-based completer generates list for given command > (entries from this list are options). Take detach-interface for > instance. This have some options: > --mac: here we want option-based completer to list mac addresses of a > NICs of a domain specified by > --domain: since this could be left out we want here command-base > completer to either list all domains, or list only those domains which > have a NIC. > > So then we get: > > # detach-interface<TAB><TAB> > --mac --persistent domain1 domain2 > > # detach-interface domain1 --mac<TAB><TAB> > 00:11:22:33:44:55 01:23:45:67:89 > > My point is - I can't see any pruning here. But maybe I've chosen wrong > example. However, this example shows we need both types of completer. > > Michal > Hi, All Are their any progress now? Thanks, Lai