Re: [Monotone-devel] overwriteable and negatable options

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On 06/14/2010 05:00 AM, Stephen Leake wrote:
>> Timothy Brownawell<address@hidden>  writes:
>>
>> Should 'full' also be in the verbosity optset? It's now deprecated, but
>> it might as well work with --no-verbose, and serve as an example of how
>> to do this right.
>
> It actually does work with it, just the only way to tell is to look at
> the setter body and see that what it sets (the 'verbosity' variable)
> is in the verbosity optset. The verbosity options are included in the
> globals, so making it in the verbosity optset would make it a global
> option too, which I'm not sure we want.

ok.


>> GOPT(format_dates ...) could be GLOBAL_SIMPLE_OPTION?
>
> It is now, and the places that look at the date format options and
> hook are all moved to a single function.

This looks good.

>> I don't think we can change 'without-header', 'with-header' to
>> 'with-header/without-header', because the resetter would also reset
>> 'reverse'. We should probably add a comment about that. Or we could not
>> have 'with-header' and 'reverse' in the same optset; then they have to
>> be specified separately in CMD option lists.
>>
>> Similarly for 'automate_inventory_opts' 'no-unknown' vs 'unknown'
>> 'unknown'; we don't want 'no-unknown' to reset the other
>> automate_inventory_opts. I don't think this is a problem for these
>> particular options; we don't need resetters in general for automate
>> options.
>
> That can be handled by putting them in their own optset (so they can be reset 
> by themselves), and then using OPTSET_REL to mark it as a child of the larger 
> optset (for convenience in specifying them for commands) -- 
> this is also how --key or the verbosity options etc can be reset
> without also resetting all the other global options. The problem with
> these specific cases is that they need a CMD_PRESET_OPTIONS or similar
> to set the default option value for the chosen command before any of
> our option sources are read, which I haven't gotten to yet.

Ok.

>> Would it be possible to specify the reset option name in the OPTSET
>> macro? That would be clearer. Each optset has a full options_type entry
>> in all_options, so the resetter could be stored there, rather than with
>> each individual option.
>
> Really, the current setup was based entirely on it being obvious and
> simple to translate to --help output. And it ends up with the help
> output being exactly as unclear as what's in options_list.hh .
>
> Right now it looks like [0]
>
>   --date-format <arg> / --default-date-format     ...text...
>   --key [ -k ] <arg> / --use-default-key          ...text...
>   --no-format-dates                               ...text...

In the particular case of dates, I don't think we need
--no-format-dates; that's the same as --default-date-format.

How many other options actually have a group reset, as opposed to a
single reset? I don't see any in options.hh, but maybe I missed
something.

If all options resetters reset only single options, then format 0 works
for me.

> or possibly treating groups with a single options specially, as [3]
>
>   Date formatting options
>     --date-format <arg>                           ...text...
>     --no-format-dates                             ...text...
>     --default-date-format                         ...text...
>   --key [ -k ] <arg> / --use-default-key          ...text...

I like 3 for group resets.

-- 
-- Stephe