From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:59
Pierre Habouzit [off-list ref] writes:
On Mon, Dec 17, 2007 at 10:53:00AM +0000, Junio C Hamano wrote:
...
quoted
This is just a quick idea before I go back to sleep, but your earlier
comment on "--no-<an-option-that-is-not-even-boolean>" made me realize
that the alternative I was suggesting earlier would actually work much
nicer, if you introduce "--<an-option-that-take-optional-arg>-default"
magic.
meeeow I love the idea !
There is a bit more serious issue than coding, actually.
Short options.
A script wants to use default rename detection threshold for unknown
commit $foo whose name might look like a number. IOW, this
git diff -M $foo
could be ambiguous. Obviously, "git diff -M-default $foo" would not fly
very well.
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:43:59
On Mon, Dec 17, 2007 at 11:21:11AM +0000, Junio C Hamano wrote:
Pierre Habouzit [off-list ref] writes:
quoted
On Mon, Dec 17, 2007 at 10:53:00AM +0000, Junio C Hamano wrote:
...
quoted
This is just a quick idea before I go back to sleep, but your earlier
comment on "--no-<an-option-that-is-not-even-boolean>" made me realize
that the alternative I was suggesting earlier would actually work much
nicer, if you introduce "--<an-option-that-take-optional-arg>-default"
magic.
meeeow I love the idea !
There is a bit more serious issue than coding, actually.
Short options.
A script wants to use default rename detection threshold for unknown
commit $foo whose name might look like a number. IOW, this
git diff -M $foo
could be ambiguous. Obviously, "git diff -M-default $foo" would not fly
very well.
Yes, I thought about that too actually.
After having written this mail 4 time already, I came up with an idea I
kind of like: like find, we could make {} be a placeholder for the
"default" argument. For example:
$ git foo --abbrev {} 10
$ git log -M {} 1
...
{} would have the same semantics as your --long-opt-default. It tells the
option parser that "no there isn't anything to grok for that command thank you
very much". Of course if for some reason you really want to pass "{}" to the
command, the stuck form holds:
$ git foo --long-opt={}
$ git foo -o{}
What do you think ?
PS: I know that in some shells {} needs escaping, which isn't nice. I chose it
because it's the same as find(1) but we could e.g. use '_' that is less
"conventional" (if it even makes sense) but is a bit easier to type than \{}.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:00
Pierre Habouzit [off-list ref] writes:
After having written this mail 4 time already, I came up with an idea I
kind of like: like find, we could make {} be a placeholder for the
"default" argument. For example:
$ git foo --abbrev {} 10
$ git log -M {} 1
...
{} would have the same semantics as your --long-opt-default. It tells the
option parser that "no there isn't anything to grok for that command thank you
very much". Of course if for some reason you really want to pass "{}" to the
command, the stuck form holds:
$ git foo --long-opt={}
$ git foo -o{}
What do you think ?
1. {} means a completely different thing to find ("place the real value
here"); there is no similarity. I would strongly oppose to it. If
you want to invoke opt with default but still want to pass "{}" as an
argument unrelated to that opt, you would do "--opt={} {}". That's
double ugly.
2. For a long option with optional option-argument, --abbrev-default (or
in the other order, --default-abbrev) to mark "there is no option
argument, do not do your context sensitive parsing" and using an
explicit '=' (e.g. --abbrev=<value>) to mark "this is the argument,
do not do your context sensitive parsing" is much more readable.
3. There are only handful options with optional option-argument that
does not have long format. I think it is reasonable to require
"stuck argument" to them. For most of the short options that take
optional option-argument, traditionally we did not allow them to be
spelled as separate words, so there is no regression to introduce
such a behaviour. -B/-M/-C options to diff family would be handled
sanely this way.
Another possibility, which I do not like very much, is to add long
format to them, if only for paranoid scripters who want rename
detection with the default threshold and cannot say "diff -M $foo".
They can say "diff --detect-rename-default $foo" instead ("-M" is a
bad example here, as giving a single path never makes sense for -M so
$foo cannot be a file whose name is e.g. "20", and default number of
abbreviated commit object name is longer than 2 which means it would
make it longer than "percentage" form of threshold).
So in short, for an option that takes optional option-argument:
- if it is given as "--<long-name>-default", there is no optional
argument, period.
- if it is given as "--long-name" but there is no next word, there is
no optional argument, either.
- if it is given as "--long-name=value", that "value" is the
argument. Barf if it does not validate.
- if it is given as "--long-name", and there is a next word, see if
that is plausible as its argument. Get it and signal the caller
you consumed it, if it is. Ignore it and signal the caller you
didn't, if it isn't.
- if it is given as "-svalue", that "value" is the argument. Barf if
it does not validate.
- if it is given as "-s", and there is a next word, and if the option
has long format counterpart as well, then see if the next word is
plausible as its argument. Get it and signal the caller you
consumed it, if it is. Ignore it and signal the caller you didn't,
if it isn't.
- if it is given as "-s" but the previous rule did not trigger, there
is no optional argument.
From: Jeff King <hidden> Date: 2016-06-15 22:44:00
On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:
So in short, for an option that takes optional option-argument:
I agree with everything you said, except...
- if it is given as "--long-name", and there is a next word, see if
that is plausible as its argument. Get it and signal the caller
you consumed it, if it is. Ignore it and signal the caller you
didn't, if it isn't.
This "plausible" makes me a little nervous, and I wonder why we want to
support this at all. Is it
1. We have traditionally supported "--abbrev 10"? I don't think this
is the case.
2. Consistency with "--non-optional-arg foo"? Do we have any such
non-optional long arguments? I didn't see any; I think we stick
with --non-optional-arg=foo everywhere.
3. More convenience to the user? I don't see how " " is easier than
"=".
- if it is given as "-s", and there is a next word, and if the option
has long format counterpart as well, then see if the next word is
plausible as its argument. Get it and signal the caller you
consumed it, if it is. Ignore it and signal the caller you didn't,
if it isn't.
Similarly, what is the goal here?
1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
shortlog's -w.
2. This would add consistency to non-optional arguments.
3. It's longer to type.
So I see a slight case for "-s foo", but none at all for "--long foo".
-Peff
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:44:00
On Mon, Dec 17, 2007 at 08:31:43PM +0000, Jeff King wrote:
On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:
quoted
So in short, for an option that takes optional option-argument:
I agree with everything you said, except...
quoted
- if it is given as "--long-name", and there is a next word, see if
that is plausible as its argument. Get it and signal the caller
you consumed it, if it is. Ignore it and signal the caller you
didn't, if it isn't.
This "plausible" makes me a little nervous, and I wonder why we want to
support this at all. Is it
1. We have traditionally supported "--abbrev 10"? I don't think this
is the case.
Yes, that's why the restriction bugs me a bit too.
2. Consistency with "--non-optional-arg foo"? Do we have any such
non-optional long arguments? I didn't see any; I think we stick
with --non-optional-arg=foo everywhere.
there are some, I don't recall the exact commands, but option parsing
was quite inconsistent in git (well still is), there are the very simple
loops that just do strcmp and look for the '=', there are the loops that
allow interleaving of options and arguments (and that rewrite argc/argv
a bit like parseopt does) and also the ones that allow the separate
mode, and the one that do both.
The force-stick-mode is a regression for them.
quoted
- if it is given as "-s", and there is a next word, and if the option
has long format counterpart as well, then see if the next word is
plausible as its argument. Get it and signal the caller you
consumed it, if it is. Ignore it and signal the caller you didn't,
if it isn't.
Similarly, what is the goal here?
1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
shortlog's -w.
Yes for git tag -n for example, and there are some other
examples, look at maint for commands that have been migrated to
parse_options, some behave like that, and more than one for sure.
3. It's longer to type.
It's way more readable, but YMMV.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:44:00
On Mon, Dec 17, 2007 at 08:42:04PM +0000, Pierre Habouzit wrote:
On Mon, Dec 17, 2007 at 08:31:43PM +0000, Jeff King wrote:
quoted
On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:
quoted
So in short, for an option that takes optional option-argument:
I agree with everything you said, except...
quoted
- if it is given as "--long-name", and there is a next word, see if
that is plausible as its argument. Get it and signal the caller
you consumed it, if it is. Ignore it and signal the caller you
didn't, if it isn't.
This "plausible" makes me a little nervous, and I wonder why we want to
support this at all. Is it
1. We have traditionally supported "--abbrev 10"? I don't think this
is the case.
Yes, that's why the restriction bugs me a bit too.
Err I misread your point, _yes_ we do, see builtin-show-ref.c, or see
--start-number in builtin-log.c. There is a precedent.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:44:00
On Mon, Dec 17, 2007 at 07:52:29PM +0000, Junio C Hamano wrote:
Pierre Habouzit [off-list ref] writes:
quoted
After having written this mail 4 time already, I came up with an idea I
kind of like: like find, we could make {} be a placeholder for the
"default" argument. For example:
$ git foo --abbrev {} 10
$ git log -M {} 1
...
{} would have the same semantics as your --long-opt-default. It tells the
option parser that "no there isn't anything to grok for that command thank you
very much". Of course if for some reason you really want to pass "{}" to the
command, the stuck form holds:
$ git foo --long-opt={}
$ git foo -o{}
What do you think ?
1. {} means a completely different thing to find ("place the real value
here"); there is no similarity. I would strongly oppose to it. If
okay we could make it be '_', but …
you want to invoke opt with default but still want to pass "{}" as an
argument unrelated to that opt, you would do "--opt={} {}". That's
double ugly.
Actually that would be --opt {} {} (or --opt _ _) and indeed it's not
very nice (euphemism for it sucks hard).
I like the *-default idea a lot, but it's not really useful if we cannot
fix the single letter switches at the same time. I had the idea to use !
(or any other less shell-magical char) like this: --abbrev! but it
doesn't fly a lot better for single letter switches.
Well maybe it's not worth fighting any longer, we should stick to the
stuck form then :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
From: Pierre Habouzit <hidden> Date: 2016-06-15 22:44:00
On Mon, Dec 17, 2007 at 11:07:29PM +0000, Jeff King wrote:
On Mon, Dec 17, 2007 at 10:01:16PM +0100, Pierre Habouzit wrote:
quoted
Err I misread your point, _yes_ we do, see builtin-show-ref.c, or see
--start-number in builtin-log.c. There is a precedent.
Ugh. Well, in that case, it seems we are stuck with it, and I think
the behavior Junio laid out is the right course of action.
Well I agree, I was mostly trying to show what the code could look like
if we tried to be more clever. I'm fine for enforcing the sticked usage
for optional flags, I was the one advocating it in the first place
anyways. I just wanted to be sure we didn't missed something obvious.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org