Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: --help trough _use_lo , but how with -h style?
- X-seq: zsh-users 3229
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Zsh Users <zsh-users@xxxxxxxxxxxxxx>
- Subject: Re: --help trough _use_lo , but how with -h style?
- Date: Wed, 28 Jun 2000 15:56:02 +0000
- In-reply-to: <20000628150234.A32686@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <20000628150234.A32686@xxxxxxxxxxxxxxxxxxxxxxxxxx> <200006281312.PAA32564@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <000e01bfe103$dcd6f650$21c9ca95@xxxxxxxxxxxxxx>
On Jun 28, 3:02pm, Matthias Kopfermann wrote:
} Subject: --help trough _use_lo , but how with -h style?
}
} Hi again,
} After I got the information about the use of `compdef _use_lo x y z' to
} have x y and z commands completed I asked myself:
} How can i do it with these `-h' commands. e.g. mutt only wants
} -x flags.
If I understand you correctly, you mean that there are at least several
commands that you use that generate help output when given `-h', and you
would like the completion system to treat `command -<TAB>' as a reason
to execute `command -h' and then parse the resulting output.
The first thing you should do (which perhaps you have) is make sure that
there aren't already completion functions for those commands. After you
have run `compinit', you can see which commands already have completions
this way:
print -l ${(ok)_comps} | less
(substitute your favorite pager). The first several lines will look like
`-something-' where `something' is the name of one of the special contexts
that the completion system understands; the rest are command names.
} [...] i have a function that does it with -h commands ,
} too, but it would be much nicer, if there was such a function in
} plain-zsh already. Thats why i ask.
If the -h output is really as consistently formatted as GNU --help (which
isn't very, I guess) then send your function off to zsh-workers and it'll
probably get included in the next release.
On Jun 28, 3:12pm, Sven Wischnowsky wrote:
} Subject: Re: --help trough _use_lo , but how with -h style?
}
} Hm, if you have a function to generate the option names you can easily
} use that. I guess the function puts the options into the $reply array
} (I'll assume the strings generated include the `-'), so you can do:
}
} _use_so() { # ;-)
} if [[ $PREFIX = -* ]]; then
} ... # call perl-function-thingy
} compadd -a reply
} else
} _default
} fi
} }
}
} To make this nicer, change the `compadd'-line to:
}
} local expl
} _wanted options expl option compadd -a reply
And to make it even nicer, _use_so should respect the `command' style for
the `options' tag and employ _call to invoke the function-thingy, which
is why I suggest that he send us the function to play with.
On Jun 28, 5:22pm, Andrej Borsenkow wrote:
} Subject: RE: --help trough _use_lo , but how with -h style?
}
} [...] What you want is a function that
} would parse general output of arbitrary command and generate useful
} completion out of this. I doubt that it ever be possible.
I don't think he's asking for quite that much.
} Please, note, that as far as I can tell --help parsing is used only in
} three completion functions currently - _configure, _tar and _gdb. Of
} these three I believe that _tar and _gdb use it only for historical
} reasons - the single command where this makes sense is _configure.
Hmm, you're right, I missed that _arguments has to be given both an option
of `--' as well as a string-to-be-completed of `--' before it will invoke
`command --help'. That would make _use_so useful even for GNU commands
that have no other default completion, assuming you could set the command
style so as to choose whether to pass -h or --help.
} Note, that parsing of help text has many drawbacks. You cannot supply
} description;
Not strictly true; if you really could parse the help text, the parser
could add the help text itself as the descriptions. I'm skeptical that
this is possible in general, but it might be possible for some specific
commands.
} you cannot define mutualy excluding options; you cannot
} define mutually dependent options or option sets. I.e. _arguments is
} much better suited - with the additional cost of writing separate
} function for every command.
Which is exactly what he wants to avoid, I suspect. We haven't yet
achieved the goal that writing a completion function is not daunting to
the average user.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author