Commit graph

7 commits

Author SHA1 Message Date
Jesse Bannon
a758a8870d
[DOCS] Overhaul configuration file getting started guide (#1172)
Updates the configuration file's docs to be cleaner. Removes sphinx autodocs entirely in favor of our custom-built one.
2026-03-09 10:18:50 -07:00
Ross Patterson
abd75f8005
[DOCS] logs: persistent logs config (#1304)
* docs(logs): Mimick argparse option default format

I find it more readable to use punctuation to separate technical information, such as
required vs optional or default values, from narrative description. Follow argparse's
lead, and put such information in parens following the narrative description.

* docs(usage): Consistent structure, clarifications

* docs(config): Clarify persist_logs behavior/opts

Clarify the `persist_logs:` options per [Discord discussion](https://discord.com/channels/994270357957648404/1409161361853780060/1409602529460879431).
2025-08-27 09:04:36 -07:00
Ross Patterson
f88b27ffec
[DOCS] Various clarifications (#1289)
* docs(preset): Config file top presets vs base

* docs(throttle): resolution/quality throttle asset

I also added the "wait a few hours and try again" hint, sorry I didn't think of this
when reviewing your PR. While doing that I also reformatted the `%concat(...)` arguments
to be more readable to me. Particularly to keep clear what punctuation is about argument
separation as opposed to punctuation meant to be included in the resulting string. Not a
strong preference if you don't like it.

* docs(various): Minor typo and formatting fixes

* docs(preset): Fix presets vs preset in config file

From [feedback](https://github.com/jmbannon/ytdl-sub/pull/1289#discussion_r2289960678).

* test(throttle): Match modified assertion text

If it were my test, I'd only make assertions on the spirit of error message text
necessary to confirm it's the right error message and not another.

* docs(throttle): More likely override value

From [feedback](https://github.com/jmbannon/ytdl-sub/pull/1289#discussion_r2289976156).
2025-08-22 07:17:32 -07:00
Ross Patterson
60ff645750
[DOCS] Consistent headings, newlines, wraps (#1293)
I've been running into variations in style in the docs I've edited so far. I've been
including changes for consistency in with other commits but in many cases that makes one
part of one doc more consistent with the rest but less consistent with itself. It seems
like a bit of cleanup may be in order.

This change applies the following conventions:

- Section heading heirarchy:
  #. ``=`` with overline for document title, IOW first heading
  #. ``-``
  #. ``~``
  #. ``"``

- Two newlines before ``-`` sections for readability

- A newline between every section of any level and the first line of text

- Wrap paragraph lines at 88 characters to match Python's Black

I've only applied these changes to those ``*.rst`` files that aren't generated.

In the future, I might suggest another bulk change to match [the Sphinx conventions for
section
headings](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections).
2025-08-20 20:20:19 -07:00
Ross Patterson
e1f81e5274
[DOCS] Add Architecture section and Quick Start (#1287)
* docs(config): Clarify preset ordering priority

Refs #1276

* docs(architecture): WIP Narrative how it works

Much of this is repetition of the reference docs and some of the changes here should
also be applied here. The goal is to repeat here the parts of the reference docs that
may hang up a user when reading "Getting Started" without sending them off to get lost
in the weeds of the reference docs.

Note that this references a `Quick Start` document which is just an empty placeholder
and is to be written in a subsequent change.

Fixes #1279

* docs(terms): Glossary redundant with architecture

Now that the introduction includes an architectural overview, that section introduces
new users to necessary concepts and associated terminology and makes the terminology
section redundant in that part of the docs.

* docs(quick): Add a rote quick start guide

This is what I came up with when I tried to write instructions requiring as little
understanding as possible. Doing so really did reinforce my impression that this just
shouldn't be done, that significant understanding is required for *any* use of ytdl-sub
and even offering a quick start may be irresponsible. I'm still on the fence, thoughts?

That said, I also think I got some good explanations out of this and a better
understanding of what the next bits of the Getting Started should be. This Quick Start
is currently redundant with other parts of the Getting Started pages. I suspect that
I'll end up repeating and/or reorganizing parts of this Quick Start into the next bits
of the Getting Started. To that end I might argue that this change is a WIP and that
merging should wait. But I could also argue that this is an incremental improvement and
can be merged before that other work. Your call.

* docs(start): Various rST/Sphinx markup issues
2025-08-19 00:38:39 -07:00
Jesse Bannon
731d4e444c
[DOCS] Tooling to auto-generate custom sphinx docs (#849)
Tooling + updating docs
2023-12-28 22:39:59 -08:00
Qualis Svagtlys
008bcf1b2d
[DOCS] Begin complete overhaul of readthedocs (#847)
Readthedocs for ytdl-sub is getting a massive overhaul to both look and read like a modernized app. It is still very-much work-in-progress, stay tuned for more!

Huge thanks to @Svagtlys (aka Momo) for driving this
2023-12-27 10:27:40 -08:00