<div dir="ltr">G_option_excludes() works for me. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
Huidae Cho wrote:<br>
<br>
> I assume G__check_option_rules() is supposed to be called by G_parser().<br>
> Then, instead of calling G_fatal_error, it should append errors to<br>
> st->errors.<br>
<br>
</div>Okay; I presume that the intent is so that it will report all errors,<br>
not just the first.<br>
<div class=""><br>
> If so... for g.mlist we can define two different versions of<br>
> rules:<br>
><br>
> This version prints more correct errors because only present options/flags<br>
> will be displayed in errors, but too much typing.<br>
>     G_option_exclusive(flag.regex, flag.extended, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.full, NULL);<br>
>     G_option_exclusive(flag.pretty, opt.output, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.mapset, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.type, NULL);<br>
>     G_option_exclusive(flag.full, opt.output, NULL);<br>
>     G_option_exclusive(flag.full, flag.mapset, NULL);<br>
>     G_option_exclusive(flag.full, flag.type, NULL);<br>
><br>
> This version is shorter, but -p -f will print three errors including<br>
> options/flags not present.<br>
>     G_option_exclusive(flag.regex, flag.extended, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.full, opt.output, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL);<br>
>     G_option_exclusive(flag.pretty, flag.full, flag.type, NULL);<br>
><br>
> Can we implement something like<br>
> G_option_exclusive(pretty, full, G_option_or(output, mapset, type))<br>
> ?<br>
<br>
</div>I'd rather stick to "flat" rules rather than heading in the direction<br>
of generalised boolean expressions.<br>
<br>
Not because it's hard to implement, but because it makes it harder to<br>
utilise the information.<br>
<br>
The next logical step is to include the rules in the<br>
--interface-description output so that the GUI can convey the<br>
relationships to the user. E.g. mutually-exclusive options might use<br>
radio buttons, or greying-out excluded options. Options which are<br>
required by another option could be marked as "required" when a value<br>
is given for the first option. And so on.<br>
<br>
Realistically, that requires that the rules belong to a finite set of<br>
patterns.<br>
<div class=""><br>
> pretty, full, and any of output, mapset, and type are mutually exclusive,<br>
> but output, mapset, and type are not exclusive.<br>
<br>
</div>How about another rule type:<br>
<br>
>     G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL);<br>
>     G_option_excludes(flag.full,   opt.output, flag.mapset, flag.type, NULL);<br>
<br>
where the first option excludes all remaining options.<br>
<br>
This is essentially the negation of G_option_requires().<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></span></blockquote></div><br></div>