nixos/doc: Improve documentation of documentation

```ShellSession

$ cd /path/to/nixpkgs

$ $EDITOR doc/nixos/manual/... # edit the manual

$ nix-build nixos/release.nix -A manual.x86_64-linux

```

There's also [a convenient development daemon](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-devmode).

**Contributing to the man pages**

The above instructions don't deal with the appendix of available `configuration.nix` options, and the manual pages related to NixOS. These are built, and written in a different location and in a different format, as explained in the next sections.

The man pages are written in [DocBook] which is XML.

## Contributing to the `configuration.nix` options documentation {#sec-contributing-options}

To see what your edits look like:

The documentation for all the different `configuration.nix` options is automatically generated by reading the `description`s of all the NixOS options defined at `nixos/modules/`. If you want to improve such `description`, find it in the `nixos/modules/` directory, and edit it and open a pull request.

To see how your changes render on the web, run again:

```ShellSession

$ nix-build nixos/release.nix -A manual.x86_64-linux

```

And you'll see the changes to the appendix in the path `result/share/doc/nixos/options.html`.

You can also build only the `configuration.nix(5)` manual page, via:

```ShellSession

$ cd /path/to/nixpkgs

$ nix-build nixos/release.nix -A manpages.x86_64-linux

$ nix-build nixos/release.nix -A nixos-configuration-reference-manpage.x86_64-linux

```

You can then read the man page you edited by running

And observe the result via:

```ShellSession

$ man --manpath=result/share/man nixos-rebuild # Replace nixos-rebuild with the command whose manual you edited

$ man --local-file result/share/man/man5/configuration.nix.5

```

If you're on a different architecture that's supported by NixOS (check file `nixos/release.nix` on Nixpkgs' repository) then replace `x86_64-linux` with the architecture. `nix-build` will complain otherwise, but should also tell you which architecture you have + the supported ones.

## Contributing to `nixos-*` tools' manpages {#sec-contributing-nixos-tools}

The manual pages for the tools available in the installation image can be found in Nixpkgs' by running (e.g for `nixos-rebuild`):

```ShellSession

$ git ls | grep nixos-rebuild.8

```

Man pages are written in [`mdoc(7)` format](https://mandoc.bsd.lv/man/mdoc.7.html) and should be portable between mandoc and groff for rendering (though minor differences may occur, mandoc and groff seem to have slightly different spacing rules.)

For previewing edited files, you can just run `man --local-file path/to/file.8` and you will see it rendered.

Being written in `mdoc`, these manpages use semantic markup. This file provides a guideline on where to apply which of the semantic elements of `mdoc`.

### Command lines and arguments {#ssec-contributing-nixos-tools-cli-and-args}

In any manpage, commands, flags and arguments to the *current* executable should be marked according to their semantics. Commands, flags and arguments passed to *other* executables should not be marked like this and should instead be considered as code examples and marked with `Ql`.

- Use `Fl` to mark flag arguments, `Ar` for their arguments.

- Repeating arguments should be marked by adding ellipses (`...`).

- Use `Cm` to mark literal string arguments, e.g. the `boot` command argument passed to `nixos-rebuild`.

- Optional flags or arguments should be marked with `Op`. This includes optional repeating arguments.

- Required flags or arguments should not be marked.

- Mutually exclusive groups of arguments should be enclosed in curly brackets, preferably created with `Bro`/`Brc` blocks.

When an argument is used in an example it should be marked up with `Ar` again to differentiate it from a constant. For example, a command with a `--host name` flag that calls ssh to retrieve the host's local time would signify this thusly:

```

This will run

.Ic ssh Ar name Ic time

to retrieve the remote time.

```

If you're on a different architecture that's supported by NixOS (check nixos/release.nix) then replace `x86_64-linux` with the architecture.

`nix-build` will complain otherwise, but should also tell you which architecture you have + the supported ones.

### Paths, NixOS options, environment variables {#ssec-contributing-nixos-tools-options-and-environment}

Constant paths should be marked with `Pa`, NixOS options with `Va`, and environment variables with `Ev`.

Generated paths, e.g. `result/bin/run-hostname-vm` (where `hostname` is a variable or arguments) should be marked as `Ql` inline literals with their variable components marked appropriately.

 - Taking `hostname` from an argument become `.Ql result/bin/run- Ns Ar hostname Ns -vm`

 - Taking `hostname` from a variable otherwise defined becomes `.Ql result/bin/run- Ns Va hostname Ns -vm`

### Code examples and other commands {#ssec-contributing-nixos-tools-code-examples}

[DocBook]: https://en.wikipedia.org/wiki/DocBook

In free text names and complete invocations of other commands (e.g. `ssh` or `tar -xvf src.tar`) should be marked with `Ic`, fragments of command lines should be marked with `Ql`.

Larger code blocks or those that cannot be shown inline should use indented literal display block markup for their contents, i.e.

```

.Bd -literal -offset indent

...

.Ed

```

Contents of code blocks may be marked up further, e.g. if they refer to arguments that will be substituted into them:

```

.Bd -literal -offset indent

{

  options.hostname = "\c

.Ar hostname Ns \c

";

}

.Ed

```

  # Generate the configuration.nix manual package

  configuration-manual = runCommand "nixos-manpages"

  nixos-configuration-reference-manpage = runCommand "nixos-configuration-reference-manpage"

    { nativeBuildInputs = [

        buildPackages.installShellFiles

        buildPackages.nixos-render-docs

# NixOS manpages

This is the collection of NixOS manpages, excluding `configuration.nix(5)`.

Man pages are written in [`mdoc(7)` format](https://mandoc.bsd.lv/man/mdoc.7.html) and should be portable between mandoc and groff for rendering (though minor differences may occur, mandoc and groff seem to have slightly different spacing rules.)

For previewing edited files, you can just run `man -l path/to/file.8` and you will see it rendered.

Being written in `mdoc` these manpages use semantic markup. This file provides a guideline on where to apply which of the semantic elements of `mdoc`.

### Command lines and arguments

In any manpage, commands, flags and arguments to the *current* executable should be marked according to their semantics. Commands, flags and arguments passed to *other* executables should not be marked like this and should instead be considered as code examples and marked with `Ql`.

 - Use `Fl` to mark flag arguments, `Ar` for their arguments.

 - Repeating arguments should be marked by adding ellipses (`...`).

 - Use `Cm` to mark literal string arguments, e.g. the `boot` command argument passed to `nixos-rebuild`.

 - Optional flags or arguments should be marked with `Op`. This includes optional repeating arguments.

 - Required flags or arguments should not be marked.

 - Mutually exclusive groups of arguments should be enclosed in curly brackets, preferably created with `Bro`/`Brc` blocks.

When an argument is used in an example it should be marked up with `Ar` again to differentiate it from a constant. For example, a command with a `--host name` flag that calls ssh to retrieve the host's local time would signify this thusly:

```

This will run

.Ic ssh Ar name Ic time

to retrieve the remote time.

```

### Paths, NixOS options, environment variables

Constant paths should be marked with `Pa`, NixOS options with `Va`, and environment variables with `Ev`.

Generated paths, e.g. `result/bin/run-hostname-vm` (where `hostname` is a variable or arguments) should be marked as `Ql` inline literals with their variable components marked appropriately.

 - Taking `hostname` from an argument become `.Ql result/bin/run- Ns Ar hostname Ns -vm`

 - Taking `hostname` from a variable otherwise defined becomes `.Ql result/bin/run- Ns Va hostname Ns -vm`

### Code examples and other commands

In free text names and complete invocations of other commands (e.g. `ssh` or `tar -xvf src.tar`) should be marked with `Ic`, fragments of command lines should be marked with `Ql`.

Larger code blocks or those that cannot be shown inline should use indented literal display block markup for their contents, i.e.

```

.Bd -literal -offset indent

...

.Ed

```

Contents of code blocks may be marked up further, e.g. if they refer to arguments that will be substituted into them:

```

.Bd -literal -offset indent

{

  options.hostname = "\c

.Ar hostname Ns \c

";

}

.Ed

```

      system.build.manual = manual;

      environment.systemPackages = []

        ++ optional cfg.man.enable manual.configuration-manual

        ++ optional cfg.man.enable manual.nixos-configuration-reference-manpage

        ++ optionals cfg.doc.enable [ manual.manualHTML nixos-help ];

    })

  manualHTML = buildFromConfig ({ ... }: { }) (config: config.system.build.manual.manualHTML);

  manual = manualHTML; # TODO(@oxij): remove eventually

  manualEpub = (buildFromConfig ({ ... }: { }) (config: config.system.build.manual.manualEpub));

  manpages = buildFromConfig ({ ... }: { }) (config: config.system.build.manual.configuration-manual);

  nixos-configuration-reference-manpage = buildFromConfig ({ ... }: { }) (config: config.system.build.manual.nixos-configuration-reference-manpage);

  options = (buildFromConfig ({ ... }: { }) (config: config.system.build.manual.optionsJSON)).x86_64-linux;