On 11/12/2016 11:49 AM, Daniel Stenberg wrote:
> Then from that, we generate the man page (as it looks today with all
> options in a single flow) and I want to generate separate web pages
> for each command line option. I hope that will allow us to write more
> documentation per command line option (which certainly happened when
> we split out the libcurl option documentation in a similar fashion)
> and make it easier to get for example sets of options that affect
> certain protocols etc. And make each option documented more
> consistently. And have them listed in a properly sorted order. =)

Could you keep an html manpage around as a generated single-flow page
for the web as well, even if you are adding a default web manpage with
links based on the abbreviated --help? I prefer the big html page for
the curl tool, I just / and what I'm looking for. Also I've given out a
bunch of help links like manpage.html#--option when people ask about
things, so if the default manpage.html will be one with links to
individual options can you please add <a name="--option".

I wonder how much more documentation each of those options needs though?
I think the important part is what they do and that is already
documented. Too much documentation not necessarily a good thing if it
makes the usage harder to understand or learn.

The global/local name I wonder if to start calling options local or
global will be confusing to the user. My opinion is we could just
document in --next what --next does not reset. "--next does not reset
the following options: --verbose, --fail-early, etc ". If it were
continued to --verbose to say "--verbose is not reset by --next" or is
global isn't that confusing for anyone who's never used --next and
requires more learning.

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-users
FAQ: https://curl.haxx.se/docs/faq.html
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-11-13