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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list