-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
docs: protect options, examples and special characters by codeblocks; create more links; apply bold style to a default value #4618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: protect options, examples and special characters by codeblocks; create more links; apply bold style to a default value #4618
Conversation
- `https://` should not be interpreted as a hyperlink.
- Special characters (`{`, `}`, `*` or `-`) should be in codeblocks with theirs name.
- Inline options or theirs examples should be in codeblocks.
- Inline code examples should be in codeblocks.
- Examples of an option should contain the option itself.
./src/streamlink_cli/argparser.py:583:129: E501 line too long (130 > 128 characters)
bastimeyer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR.
Argparse help texts can't contain any restructured text markup, because it'll make the output of the --help CLI argument look bad, as it simply outputs it as plain text. That's the reason why the ext_argparse sphinx extension applies filters via regexes (which is the best it can do), so that the rendered HTML docs and man page can contain extra markup. There's already stuff in the help texts which doesn't actually belong there.
The first three commits look fine.
The fourth and fifth should be squashed, and the reST markup get removed.
If we want to add markup to the help texts, then the output of argparse needs to be modified and the markup be removed on runtime.
|
Hi @bastimeyer , thanks for your review.
OK, I will do that.
I agree. Codeblocks (double backticks) in help message look bad. Example: $ streamlink --help
...
The value can contain formatting variables surrounded by curly braces,
``{`` and ``}``. If you need to include a brace character, it can be escaped
by doubling, e.g. ``{{`` and ``}}``.
...
Well, removing markup on runtime doesn't sound easy... I'm wondering that if I should split this into two pull requests. The one contains the first three commits since they look fine, and the other should be a docstring cleanup PR. Your opinion? |
It isn't even possible without fully parsing it, which we're not going to do, because not only would it be unnecessarily slow, but it would also require adding another runtime dependency.
Sure, why not... |
|
Why did you open a new PR for the first three commits? I thought you wanted to update this PR and open a new one for the remaining changes. Going to close this one here then... |
|
Hi @bastimeyer ,
I'm sorry I thought that removing two commits from this PR would make other people confused, so I opened a new one with the commits cherry-picked from here... Thank you for helping me close this PR. |
Hello!
cc1036b :
a6280e8 :
76a910d :
1e12d02 (partial):
Please correct me if I changed the meaning of the docs.