On 11/08/2017 04:53 PM, Eric Blake wrote: > On 11/08/2017 09:09 AM, Michal Privoznik wrote: >> On 11/08/2017 03:46 PM, Martin Kletzander wrote: >>> On Tue, Nov 07, 2017 at 01:22:56PM +0100, Michal Privoznik wrote: >>>> Signed-off-by: Michal Privoznik <mpriv...@redhat.com> > >>> >>> When I see all the things you have to do here, wouldn't it be easier to >>> have a >>> virsh 'option' rather than a 'command' so that we don't have to parse >>> anything >>> twice and just circumvent the command execution in virsh itself? >> >> Not really. That would mean parsing the command line in cmdComplete. >> Which again might be incomplete and thus yet more code would be needed. >> I don't really see a problem with this approach - now that the bash >> script is written. >> >>> You >>> would just >>> run the same command with '-C' (for example) appended after the program >>> name. >> >> Yeah, there are dozen of other approaches. I've chosen this one. I'm >> failing to see why one is better than another one. >> > > [I haven't read this thread closely yet, just adding a drive-by comment] > > Several years ago, when autocompletion was attempted (and failed) as a > GSoC project, I had several ideas on how completion should work, and how > it should be tested. > > Ideally, we need a new virsh command 'complete', which takes varargs, > and then performs completion based on those args. So the bash script > for completion for this scenario: > > $ virsh some-command --arg partial<TAB><TAB> > > is as simple as having the completion function in bash call: > > $ virsh complete some-command --arg partial<TAB><TAB>
This is excatly what my patches are doing. With one tiny difference. In fact bash script calls: virsh complete "some-command --arg partial" so that I can have cmdComplete which takes exactly one string argument. Parsing of the string is then done within cmdComplete. I don't think that we have variable args in virsh for commands, do we? > > The complete command in virsh should then know that it is performing > completion on some-command, and do enough arg parsing to determine how > to complete 'partial' in the current context of whatever argument > some-command would be parsing at that point. > > If a user in bash backs up the cursor and types <TAB> somewhere other > than the end of the line, hopefully bash gives us enough hooks to call > 'virsh complete args-up-to-TAB' by merely truncating whatever appears > beyond the point where the user attempted tab completion. > > ALL the completion logic lives in virsh, nothing in bash - all bash has > to do is insert 'complete' and call into virsh. That is, once you've > written the bash script, it should NEVER need future modification, > because any further improvements to completion will live in virsh > (whether you use virsh in interactive mode or in batch mode from the shell). Correct. And again, my patches do this. For instance: virsh -r -c qemu+ssh://host/system domifaddr --domain<TAB><TAB> becomes: virsh -r -c qemu+ssh://host/system complete "domifaddr --domain" And it's the 'complete' command that is responsible for bringing up a list of possible strings. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
