From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Assorted _arguments arguments
Date: Mon, 8 May 2000 17:58:14 +0000 [thread overview]
Message-ID: <1000508175816.ZM17624@candle.brasslantern.com> (raw)
In-Reply-To: <hvowvl5nllu.fsf@serein.m17n.org>
On May 8, 11:00am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: sudo completion problem
}
} Zefram wrote:
}
} > If we can determine that a particular command is processing options in
} > this way, it would be nice to complet options accordingly. However,
} > by default options should only be completed before the first non-option
} > argument. In either case, options should never be completed after a "--".
}
} I don't buy this. There *may* be commands or shell functions which
} take `--' to, e.g., separate different sets of options and arguments.
As an example, consider writing a completer for the old compctl command,
following a -x option.
} _arguments is intended to be general enough to generate sensible
} completions even for user-written shell functions, after all.
I'm with Sven here. I don't think making _arguments more specialized is
the right thing. There should perhaps be a fairly trivial way to tell it
to stop completing options after a non-option argument, including `--' as
a non-option, but otherwise I think it may already even go too far in
treating words that begin with a `-' specially.
} But before I start writing it: should the default for _arguments be
} changed? And would someone be willing to check all uses of _arguments
} and add the option to the calls that need them?
I don't think it makes a lot of difference which way the default goes;
do whatever would require the fewest changes to _arguments and to all
the other functions that call it.
On May 8, 11:44am, Sven Wischnowsky wrote:
} Subject: Re: optional argument?
}
[Tanaka-san wrote:]
} > This is caused by optional argument for --context. In this position,
} > _diff_options should completes only new files: second file set. In
} > general, optional argument of _arguments always causes similar
} > problem, I think. So, I think it is bit confused and not so useful.
}
} Hrmpf. Make `='-options complete the argument *only* after the equal
} sign? Add a new specification type, say `-opt==' for options that
} don't accept the argument in a separte word (should the long-option
} auto-detection code use it then?)?
On May 8, 11:49pm, Tanaka Akira wrote:
} Subject: Re: optional argument?
}
} Actual commands which has optional arguments judge whether they are
} specified or not in a some criteria. So, supporting some common
} criteria is useful.
}
[...]
}
} Exactly, the existence of `=' is the criteria used by getopt_long. So
} it's good. But I vote `-opt=?' instead of `-opt=='.
I think we should try to make the syntax consistent with `getopts' and
`zparseopts' if possible. Maybe that _isn't_ possible do to conflicting
use of colons ... and maybe we should have thought of that before we used
colons everywhere, but ...
} Note that another common criteria is that a optional argument must be
} some set of strings: `yes' or `no' for example. At least, xset
} handles optional arguments in this way. If we can specify a pattern
} addition to the current optional argument syntax, it can be handled.
If there's a known set of strings that can be the optional argument, then
I think this can be handled with state changes and/or alternation and we
don't need any more patterns jammed into the opt-spec.
} Apart from that, I hope a extension for _arguments. There are
} many duplicated descriptions such as:
}
} '(-i)--ignore-case[case insensitive]' \
} '(--ignore-case)-i[case insensitive]' \
} '(-w)--ignore-all-space[ignore all white space]' \
} '(--ignore-all-space)-w[ignore all white space]' \
}
} So, I really want to describe them as:
}
} '--ignore-case,-i[case insensitive]' \
} '--ignore-all-space,-w[ignore all white space]' \
}
} In other words, I think it is useful that opt-spec is comma separated
} list of options. And exclusive options are automatically set up each
} other if they are not prefixed as `*'.
On a similar topic, can anyone think of a way to write an exclusive-or
glob pattern? E.g. I want to match ChangeLog if that exists, or Changes
if that exists, but neither if both exist?
Returning to the original topic, perhaps a better way to think of this
is that -i and --ignore-case are synonyms and should get the same
treatment and description. E.g. your suggestion does not help with
a case like
_bzip2: '(--decompress --compress -z --test -t)-d[decompress]' \
_bzip2: '(-d --compress -z --test -t)--decompress[decompress]' \
_bzip2: '(--compress --decompress -d --test -t)-z[compress]' \
_bzip2: '(-z --decompress -d --test -t)--compress[compress]' \
where you have both options that have alternate names for each other and
are mutually exclusive with other options. Much better would be, say,
'-d(--decompress)' '-z(--compress)' '-t(--test)' \
'(-z -t)-d[decompress]' \
'(-d -t)-z[compress]' \
'(-z -d)-t[test compressed file integrity]' \
It might even be able to compute this automatically from the comma-lists
in --help output, or some such. (No, I don't really like the `-x(--xxx)'
syntax, but I haven't time to think harder about it just now.)
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~2000-05-08 17:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-08 9:00 PATCH: Re: sudo completion problem Sven Wischnowsky
2000-05-08 9:44 ` optional argument? Sven Wischnowsky
2000-05-08 10:01 ` Peter Stephenson
2000-05-08 14:49 ` Tanaka Akira
2000-05-08 17:58 ` Bart Schaefer [this message]
2000-05-08 18:12 ` Assorted _arguments arguments Peter Stephenson
2000-05-08 15:25 ` PATCH: Re: sudo completion problem Tanaka Akira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1000508175816.ZM17624@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).