ArgParser: Don't show headers for empty sections.

[h-2]

OUTPUT OPTIONS
    -o, --output (std::string)
          File to hold reports on hits (.m* are blastall -m* formats; .m8 is tab-seperated .m9 is tab-seperated with
          with comments, .m0 is pairwise format). Default: output.m8. Valid output file formats: m0, m8, m9, bam, sam,
          gz, bz2.
    --percent-identity (signed 32 bit integer)
          Output only matches above this threshold (checked before e-value check). Default: 0. Value must be in range
          [0,100].
    -e, --e-value (double)
          Output only matches that score below this threshold. Default: 0.0001. Value must be in range [0,100].
    -n, --num-matches (signed 32 bit integer)
          Print at most this number of matches per query. Default: 256. Value must be in range [0,10000].

GENERAL OPTIONS

SEEDING / FILTRATION
    --seed-offset (unsigned 32 bit integer)
          Offset for seeding (if unset = seed-length/2). If you set 'seed-length', please consider setting this option
          to 'seedLength / 2'. Default: 7. Value must be in range [1,50].

GENERAL OPTIONS should not be displayed, because there are no general options (just visible with -hh).

[smehringer]

I think this cannot be done automatically in our design... because I add the print_this/that calls directly to a list of function calls and I cannot check whether the print succeeding the current is another print_section or a print_option_info in order to evaluate if the list for this subsection is empty.

One way would be to allow the add_subsection() member func to get a second parameter that this section is a option_spec::ADVANCED-only (sub)section... (should probably take a boolean which is otherwise defaulted to false)

What do you think?

[rrahn]

So to get me right, General Options is automatically generated by the parser - no user input required? But it‘s content is only displayed if -hh is passed to the parser? I am not familiar with the structure of the parser, but would it then not make sense to keep the automagically hidden arguments in a separate list and also only add the sections when required by the user? Just a thought, but I am not familiar with the design.

[smehringer]

So to get me right, General Options is automatically generated by the parser

No. This was Hannes (with myparser.add_section("General Options")).

it then not make sense to keep the automagically hidden arguments in a separate list

Then I would have to still signal the add_section call that it must go to the separate list of hidden options. And then the order gets messed up because when printing the advanced help, all options and section in the separate list are printed after all the others and not in the developer-provided order of add_option-calls (this is the case now.)

[rrahn]

Ok I see. But the problem with the advanced section is that it is not possible to combine hidden with non hidden options. You could argue that one should only use the advanced section if all options are advanced. But I think that this is not a strong design, as there are ways to use it wrong. So the behavior should be rather that a section or the parser should know when it is empty or not.

[smehringer]

Yes you are right but I don't see a clean way to do that in out current design because we store all add_* as function calls :( I would need to clumsily store an extra array keeping track of add_sections vs. add_foo and then make queries before printing..

[rrahn]

yes, there would be some work about it. Though, this is not a major issue and not relevant for the current or next release. Let's see how we can schedule it.