Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 1/2] parse_options: Add flag to prevent errors for further processing

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:48

Pierre Habouzit [off-list ref] writes:
On Wed, Jun 18, 2008 at 05:13:02AM +0000, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
I think the only right way to accomplish this is to convert the revision
and diff parameters into a parseopt-understandable format.
Not necessarily.  You could structure individual option parsers like how
diff option parsers are done.  You iterate over argv[], feed diff option
parser the current index into argv[] and ask if it is an option diff
understands, have diff eat the option (and possibly its parameter) to
advance the index, or allow diff option to say "I do not understand this",
and then handle it yourself or hand it to other parsers.
If you do that, you need to relocate pars option structures,...
... Note that "recursing"
is not really trivial, because with flags aggregation and stuff like
that, things that look like an option can also be a value in the context
of an other option parser.
Note that I was just saying "not necessarily" in response to "the only
right way" to point out it is not the _only_ way.

Parse-options has been done in a tablish way and it would involve cost to
modify it in a way I outlined (even if such a rewrite would make chaining
different set of option parsers easier, as each parser needs to handle
only what it knows about and handling aggregation and stuff would become
trivial).  I do not know if it is worth the cost, and I am not married to
the option parser structure that diff and revision part uses.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help