Make doc docs match the docs

develop
Myk 2022-09-03 20:00:38 -07:00 committed by GitHub
parent 587014b7b9
commit ef1e85e6ff
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 8 deletions

@ -16,10 +16,10 @@ Python tool named `Sphinx <https://www.sphinx-doc.org>`_.
The DFHack build process will compile and install the documentation so it can be The DFHack build process will compile and install the documentation so it can be
displayed in-game by the `help` and `ls` commands (and any other command or GUI that displayed in-game by the `help` and `ls` commands (and any other command or GUI that
displays help text), but this is disabled by default due to the additional Python and displays help text), but documentation compilation is disabled by default due to the
Sphinx requirements. If you already have a version of the docs installed (say from a additional Python and Sphinx requirements. If you already have a version of the docs
downloaded release binary), then you only need to build the docs if you're changing them installed (say from a downloaded release binary), then you only need to build the docs
and want to see the changes reflected in your game. if you're changing them and want to see the changes reflected in your game.
You can also build the docs if you just want a local HTML- or text-rendered copy, though You can also build the docs if you just want a local HTML- or text-rendered copy, though
you can always read the `online version <https://dfhack.readthedocs.org>`_ too. you can always read the `online version <https://dfhack.readthedocs.org>`_ too.
@ -183,11 +183,14 @@ And documentation for the ``autodump`` plugin might look like::
Usage help Usage help
---------- ----------
The first section after the header and introductory text should be the usage block. You can The first section after the header and introductory text should be the usage section. You can
choose between two formats, based on whatever is cleaner or clearer for your syntax. The first choose between two formats, based on whatever is cleaner or clearer for your syntax. The first
option is to show usage formats together, with an explanation following the block:: option is to show usage formats together, with an explanation following the block::
Usage:: Usage
-----
::
build-now [<options>] build-now [<options>]
build-now here [<options>] build-now here [<options>]
@ -206,7 +209,8 @@ option is to show usage formats together, with an explanation following the bloc
The second option is to arrange the usage options in a list, with the full command The second option is to arrange the usage options in a list, with the full command
and arguments in monospaced font. Then indent the next line and describe the effect:: and arguments in monospaced font. Then indent the next line and describe the effect::
Usage: Usage
-----
``build-now [<options>]`` ``build-now [<options>]``
Scan the entire map and build all unsuspended constructions Scan the entire map and build all unsuspended constructions
@ -224,6 +228,9 @@ Note that in both options, the entire commandline syntax is written, including t
Literal text is written as-is (e.g. the word ``here`` in the above example), and text that Literal text is written as-is (e.g. the word ``here`` in the above example), and text that
describes the kind of parameter that is being passed (e.g. ``pos`` or ``options``) is enclosed in describes the kind of parameter that is being passed (e.g. ``pos`` or ``options``) is enclosed in
angle brackets (``<`` and ``>``). Optional elements are enclosed in square brackets (``[`` and ``]``). angle brackets (``<`` and ``>``). Optional elements are enclosed in square brackets (``[`` and ``]``).
If the command takes an arbitrary number of elements, use ``...``, for example::
prioritize [<options>] <job type> [<job type> ...]
Examples Examples
-------- --------