On 01/08/2013 01:02 PM, Michal Privoznik wrote:
> Going over my local git branches, I found old patch set which I was trying to get in once.
> Along guest IP address patches I feel like this one is desired as well and keeps returning
> to us from time to time.
>
> What I think this feature should look like:
>
> virsh # sta<TAB>
>
> expands to:
>
> virsh # start
>
> Now, hitting <TAB> again (okay, several times actually) gives us a list of supported options:
>
> --autodestroy --bypass-cache --console --force-boot --paused
> virsh # start --
>
> Up to here, it's just current implementation. What I'd like to see is list of
> (ideally shut off) domains:
>
> --autodestroy --bypass-cache --console --force-boot --paused f17 f18 <...>
> virsh # start --
>
> The same applies to complete a single option as well. That is not (only) command based completer,
> but a option based one. IIRC, that was conclusion on my first approach as well. What I've come up with so far is:
>
> diff --git a/tools/virsh.h b/tools/virsh.h
> index ab7161f..c7cdb3a 100644
> --- a/tools/virsh.h
> +++ b/tools/virsh.h
> @@ -146,6 +146,8 @@ typedef struct _vshCmdOptDef vshCmdOptDef;
> typedef struct _vshControl vshControl;
> typedef struct _vshCtrlData vshCtrlData;
>
> +typedef char ** (*vshCmdOptCompleter)
> + (const vshCmdDef *cmd, const char *optname, void *opaque);
> /*
> * vshCmdInfo -- name/value pair for information about command
> *
> @@ -162,11 +164,13 @@ struct _vshCmdInfo {
> * vshCmdOptDef - command option definition
> */
> struct _vshCmdOptDef {
> - const char *name; /* the name of option, or NULL for list end */
> - vshCmdOptType type; /* option type */
> - unsigned int flags; /* flags */
> - const char *help; /* non-NULL help string; or for VSH_OT_ALIAS
> - * the name of a later public option */
> + const char *name; /* the name of option, or NULL for list end */
> + vshCmdOptType type; /* option type */
> + unsigned int flags; /* flags */
> + vshCmdOptCompleter completer; /* option arguments completer */
> + void *opaque; /* value to pass to @completer */
> + const char *help; /* non-NULL help string; or for VSH_OT_ALIAS
> + * the name of a later public option */
> };
>
>
>
> One of the biggest problem with this is - I'd have to change all of option definitions
> (add 'NULL, NULL, ' to all of them). Apart from huge impact, we still want command based completer,
> otherwise we would only complete:
>
> f17 f18 <...>
> virsh # start --domain <TAB>
>
> Who's really typing '--domain'? The idea is to make users life easier, not harder.
Each command has several arguments whose meaning can be positionally
determined, and the meaning of a non-"--" arg in any position can be
derived from the information in that command's option list. I think that
the autocomplete should only list possible alternatives for the current
positionally-determined argument *unless* there is already a "-" just to
the left of the cursor, and then it should provide a list of --options.
I say this because most of the time it is the positional argument that
people want, not one of the options. (Of course, once the commandline
already has all arguments that could be identified positionally, then it
would make sense to provide a list of options when someone typed <TAB>
while sitting just past a space).
This way, if you typed:
virsh # start <TAB>
you would be provided only with a list of domains (btw, the list in this
case should only include inactive domains :-), but if you typed
virsh # start -<TAB>
you would get the list of options. Once the domain name is there:
virsh # start f18 <TAB>
would give you a list of --options, because there are no more possible
positionally-determined args left.
Similarly, if you entered:
virsh # update-device <TAB>
you would again get just a list of domains; Once you have a domain on
the line, if you hit tab:
virsh # update-device f18 <TAB>
you would get a list of files in the current directory, etc.
> My aim to write this e-mail is:
> 1) let you know somebody is working on this
> 2) get your thoughts and opinions.
I think about this/wish for it at least once a week :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list