[GRASS-dev] Adding an expert mode to the parser

[Vaclav Petras]

On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo <veroandreo at gmail.com>
wrote:

> I'm with MaDi in that if I see a very long list of flags and parameters in
> the terminal when using --h, i just go to the manual... I just use --h in
> CLI for a quick recalling of flags/options... A reduced list of most
> commonly used flags would be nice, but still keep the possibility to get
> the advanced flags/parameters as well, if the user needs more info...
>

If the --help is just for scanning and the issue is that it simply too
long, hiding some parameters is not the only option we have. For many (and
more in the future hopefully) parameters we have (short) label and (longer)
description. --help prints both (if both are present, that's at least 2
lines per parameter). Additionally, if the option has predefined values
which have descriptions, there is one line for each of those. So, the
question is would it be helpful (at least as a first step) if --help would
print less information for each parameter but still provided all parameters?


> and the same in the GUI
>

In the case of GUI, we should first answer the question why are the
sections/tabs not enough? Because they already should separate basic and
advanced while providing actually much finer and partially self-documenting
way (for example, you fill in Required tab, go also to Selection, but leave
aside Transformation and Advanced tabs).


> and manual pages then (a tab or section for advanced flags/parameters)...
>
>
Considering that we have currently as system of (gui) sections which place
the options to individual tabs in GUI, isn't showing the different sections
in the manual the right thing to do? This would not only make the manual
more organized, but it would also link the manual more to the GUI.
Depending how good and smart are we with the styling and JavaScript we can
even hide some by default. But perhaps there is a reason why this is not
enough.


> IMHO, a major issue however is the lack of examples for the usage of more
> advanced flags or options (or even the required and more common ones). Take
> the case of several i.* modules, for example... but maybe this should go in
> a separate thread :-)
>

Good point. If you have an explanation and example for a flag, perhaps you
can understand it and it is not so advanced at the end.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160926/c8c24fc9/attachment.html>