On 20.07.2011 10:42, Lai Jiangshan wrote:
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
Unfortunately no. I've got distracted by other stuff (like QoS). But I
agree it is feature which will increase user friendliness of virsh. No
doubt about it. That's why I started to work on it. I hate typing whole
names, if it is obvious which one I mean.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list