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 <mprivozn(a)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