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

[Michal Privoznik]

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