[libvirt] [PATCHv3 2/6] virsh: Add vshCmdCompleter and vshOptCompleter

[Tomas Meszaros]

On 28/08/13 at 06:00am, Eric Blake wrote:
> [re-adding the list, which was accidentally omitted]
> 
> On 08/28/2013 05:26 AM, Tomas Meszaros wrote:
> >> Per-option completions make sense.  For example, 'virsh vol-key --pool
> >> <TAB>' wants to use a pool completer, while 'virsh vol-key --vol <TAB>'
> >> wants to use a volume completer; furthermore, 'virsh vol-key <TAB>'
> >> should be the combination of the option completer (showing --vol and
> >> --pool) AND the volume completer filtered to names not starting with '-'
> >> (since virsh has the semantics that arguments are positional, where the
> >> option '--vol' is implied if the argument that appears in that position
> >> does not resemble an option).
> > 
> > So If I get it right, you are suggesting that it should work like this:
> > 
> > virsh # vol-key <TAB>
> > vol1	vol2	pool1	pool2
> > 
> > as you said, combination of --vol and --pool completers.
> 
> No, it should work like this:
> 
> virsh# vol-key <TAB>
> vol1 vol2 --vol --pool
> 
> the combination of all (non-option) completions for the current
> available mandatory option (volume completer), and of all possible
> options that still make sense at this point in the command line.
> 
> Likewise:
> 
> virsh# vol-key vol <TAB>
> pool1 pool2 --pool
> 
> virsh# vol-key -<TAB>
> --vol --pool
> 
> virsh# vol-key v<TAB>
> vol1 vol2
> 
> virsh# vol-key --pool <TAB>
> pool1 pool2
> 
> virsh# vol-key --pool pool1 <TAB>
> vol1 vol2 --vol
> 
> and so forth.
>
> > 
> > 
> > I was initially thinking that completion should work like this:
> > 
> > virsh # vol-key <TAB>
> > vol1	vol2
> > 
> > It is completing <vol> first becasue <vol> is only mandatory argument
> > for this command.
> 
> It is a mandatory option, but mandatory options need not come first.
> Remember, our option parser allows mandatory options to occur
> positionally without an option name, OR to be interleaved in any other
> order by including the option string.
> 
> > 
> > 
> > Only if someone type:
> > 
> > virsh # vol-key --pool <TAB>
> > pool1	pool2
> > 
> > then call --pool completer.
> 
> This is correct - once an option is awaiting an argument, then the
> option completer must return nothing at that point in time.  But if you
> look at it as the union of two completers - the set of options that are
> still valid in the current context, and the set of strings that are
> valid assuming positional semantics of the current option, you will
> always get the right answer, without needing a per-command completer
> (just per-option completers).
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
> 
> 

Yeah, It makes more sense.
I'm now rewriting the whole stuff to just use opt completers.

-- 
Tomas Meszaros