<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 7:13 AM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 26/09/16 23:50, Vaclav Petras wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
On Mon, Sep 26, 2016 at 5:24 PM, Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a><br></span><span class="gmail-">
<mailto:<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>>> wrote:<br>
<br>
I'm with MaDi in that if I see a very long list of flags and<br>
parameters in the terminal when using --h, i just go to the<br>
manual... I just use --h in CLI for a quick recalling of<br>
flags/options... A reduced list of most commonly used flags would be<br>
nice, but still keep the possibility to get the advanced<br>
flags/parameters as well, if the user needs more info...<br>
<br>
<br>
If the --help is just for scanning and the issue is that it simply too<br>
long, hiding some parameters is not the only option we have. For many<br>
(and more in the future hopefully) parameters we have (short) label and<br>
(longer) description. --help prints both (if both are present, that's at<br>
least 2 lines per parameter). Additionally, if the option has predefined<br>
values which have descriptions, there is one line for each of those. So,<br>
the question is would it be helpful (at least as a first step) if --help<br>
would print less information for each parameter but still provided all<br>
parameters?<br>
</span></blockquote>
<br>
In line with your other mail where you caution about "hiding" useful information, how about not changing the --help output, but rather adding a "--simple-help" or somthing like this which would output a simplified help.</blockquote><div><br></div><div>+1.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Although:<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
and manual pages then (a tab or section for advanced<br>
flags/parameters)...<br>
<br>
<br>
Considering that we have currently as system of (gui) sections which<br>
place the options to individual tabs in GUI, isn't showing the different<br>
sections in the manual the right thing to do?<br>
</blockquote>
<br></span>
I would prefer this: show everything, but structure it differently, i.e. possibly introduce a new parser keyword (advanced: yes) which would put the option into a specific section of the manual. IMHO, this should be independent of the GUI sections logic as one might to group less advanced and advanced options in the same thematic tab...</blockquote><div><br></div><div>+1 also here :-) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
IMHO, a major issue however is the lack of examples for the usage of<br>
more advanced flags or options (or even the required and more common<br>
ones). Take the case of several i.* modules, for example... but maybe<br>
this should go in a separate thread :-)<br>
</blockquote>
><br>
><br>
> Good point. If you have an explanation and example for a flag, perhaps<br>
> you can understand it and it is not so advanced at the end.<br>
<br></span>
I think this is actually a major issue: man pages without description, notes and example sections are almost useless IMHO. At the <a href="http://foss4g.be" rel="noreferrer" target="_blank">foss4g.be</a> last week someone presented a simple use of GRASS GIS (to create this map [1] for television) and explained how he actually found the GRASS GIS manual system extremely well done and useful, because of the explanations and examples...<br></blockquote><div><br></div><div>+1000 :-) </div><div>So this afternoon at the GRASS meetup [<a href="https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016">https://grasswiki.osgeo.org/wiki/GRASS_GIS_Ispra_meetups_2016</a>] we can give a meaningful example on how users can contribute to GRASS without coding :-) </div><div><br></div><div>Cheers,</div><div>madi</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Moritz<br>
<br>
[1] <a href="http://www.rtbf.be/services/meteo/apere" rel="noreferrer" target="_blank">http://www.rtbf.be/services/me<wbr>teo/apere</a><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/grass-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><font color="#666666">Margherita Di Leo</font></div></div></div></div></div></div></div></div></div>
</div></div>