Huidae Cho wrote: > I assume G__check_option_rules() is supposed to be called by G_parser(). > Then, instead of calling G_fatal_error, it should append errors to > st->errors.
Okay; I presume that the intent is so that it will report all errors, not just the first. > If so... for g.mlist we can define two different versions of > rules: > > This version prints more correct errors because only present options/flags > will be displayed in errors, but too much typing. > G_option_exclusive(flag.regex, flag.extended, NULL); > G_option_exclusive(flag.pretty, flag.full, NULL); > G_option_exclusive(flag.pretty, opt.output, NULL); > G_option_exclusive(flag.pretty, flag.mapset, NULL); > G_option_exclusive(flag.pretty, flag.type, NULL); > G_option_exclusive(flag.full, opt.output, NULL); > G_option_exclusive(flag.full, flag.mapset, NULL); > G_option_exclusive(flag.full, flag.type, NULL); > > This version is shorter, but -p -f will print three errors including > options/flags not present. > G_option_exclusive(flag.regex, flag.extended, NULL); > G_option_exclusive(flag.pretty, flag.full, opt.output, NULL); > G_option_exclusive(flag.pretty, flag.full, flag.mapset, NULL); > G_option_exclusive(flag.pretty, flag.full, flag.type, NULL); > > Can we implement something like > G_option_exclusive(pretty, full, G_option_or(output, mapset, type)) > ? I'd rather stick to "flat" rules rather than heading in the direction of generalised boolean expressions. Not because it's hard to implement, but because it makes it harder to utilise the information. The next logical step is to include the rules in the --interface-description output so that the GUI can convey the relationships to the user. E.g. mutually-exclusive options might use radio buttons, or greying-out excluded options. Options which are required by another option could be marked as "required" when a value is given for the first option. And so on. Realistically, that requires that the rules belong to a finite set of patterns. > pretty, full, and any of output, mapset, and type are mutually exclusive, > but output, mapset, and type are not exclusive. How about another rule type: > G_option_excludes(flag.pretty, opt.output, flag.mapset, flag.type, NULL); > G_option_excludes(flag.full, opt.output, flag.mapset, flag.type, NULL); where the first option excludes all remaining options. This is essentially the negation of G_option_requires(). -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev