Zsh Mailing List Archive
Messages sorted by:
Re: Please add pinfo completion
- X-seq: zsh-workers 22865
- From: Andrey Borzenkov <arvidjaar@xxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: Please add pinfo completion
- Date: Wed, 11 Oct 2006 19:43:38 +0400
- In-reply-to: <200610110933.k9B9XJTB021853@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20061007013551.GE8188@xxxxxxxxxxxxxxxxxxx> <200610110648.45199.arvidjaar@xxxxxxxxxx> <200610110933.k9B9XJTB021853@xxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Was it intentionally sent to me personally and not to list?
On Wednesday 11 October 2006 13:33, you wrote:
> Andrey Borzenkov wrote:
> > On Tuesday 10 October 2006 21:59, Peter Stephenson wrote:
> > > OK, here is _arguments updated to provide option descriptions from
> > > --help text automatically.
> > I do not think it should be done unconditionally.
> Do what unconditionally?
> Running --help has never been done unconditionally,
I should not answer 5 minutes before going off to work :(
> only under the
> control of specific completions like _tar and _configure, or if
> requested via _gnu_generic. That hasn't changed; I've only upgraded
> the way it fetches descriptions. There is some minimal sanity checking
> for some of these programmes and I would be happy to add more.
I misunderstood your patch. I assumed it was now calling 'command --help' for
all _arguments invocations and was using its output in preference to
descriptions given on command line.
OK so we now have two possiblities
- - nice localized output but without any possibility to give specific options'
- - unlimited freedom in completing options limited to hardcoded english
Now when you are probably the only person understanding how _argument works -
any chances to merge the above? I.e. extra option to _arguments (something
like _agruments -h help_option, where help_option is variable) to request
description for options? This does not need all this hairy processing or
recognizing of *=FILE or like - just fetch options with help text and use it
instead of supplied one if found. This gives l10n for large part of commands
I leave the rest for list to see (I do not see any personal info here :)
> For example, we could ensure that "configure" was run with an explicit
> path such as ./configure or ../configure and if not refuse to run it
> with --help; or we could refuse to do it as root without a further style
> set by the user.
> The descriptions themselves have never been printed unconditionally,
> only under the control of the verbose option. You can turn this off,
> for example, for tar completion under all contextual completers with
> zstyle ':completion::*:tar:*' verbose false
> > And finally it opens up a can of worms that is called l10n. Now-a-days
> > you almost sure gets localized help output; so be prepared for questions
> > "why this one appears in Russian and this one not" :)
> This is surely a great deal easier for automatically generated
> descriptions than otherwise; none of LC_* or LANG are reset in
> _arguments. The only big issue I can see is with the additional logic
> to match *=FILE* and *=(DIR|PATH)* patterns and turn them into the
> appropriate sort of completion.
> A simple hash-bashed function system for localization of this sort of
> thing wouldn't be too hard to implement; it's a much easier task than
> doing the same for the main shell.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
-----END PGP SIGNATURE-----
Messages sorted by: