forked from mirrors/nixpkgs
doc,nixos/doc: unescape ellipses
Leftovers from the CommonMark conversion.
This commit is contained in:
parent
e9e65810ac
commit
3f6fed2e59
|
@ -199,7 +199,7 @@ It’s important to test any executables generated by a build when you change or
|
|||
|
||||
### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
|
||||
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
|
||||
|
||||
## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
|
||||
|
||||
|
|
|
@ -313,7 +313,7 @@ prefer to keep the layout definitions inside the NixOS configuration.
|
|||
|
||||
Unfortunately, the Xorg server does not (currently) support setting a
|
||||
keymap directly but relies instead on XKB rules to select the matching
|
||||
components (keycodes, types, \...) of a layout. This means that
|
||||
components (keycodes, types, ...) of a layout. This means that
|
||||
components other than symbols won't be loaded by default. As a
|
||||
workaround, you can set the keymap using `setxkbmap` at the start of the
|
||||
session with:
|
||||
|
|
|
@ -149,7 +149,7 @@ multiple modules, or as an alternative to related `enable` options.
|
|||
|
||||
As an example, we will take the case of display managers. There is a
|
||||
central display manager module for generic display manager options and a
|
||||
module file per display manager backend (sddm, gdm \...).
|
||||
module file per display manager backend (sddm, gdm ...).
|
||||
|
||||
There are two approaches we could take with this module structure:
|
||||
|
||||
|
|
|
@ -324,7 +324,7 @@ Composed types are types that take a type as parameter. `listOf
|
|||
: Type *`t1`* or type *`t2`*, e.g. `with types; either int str`.
|
||||
Multiple definitions cannot be merged.
|
||||
|
||||
`types.oneOf` \[ *`t1 t2`* \... \]
|
||||
`types.oneOf` \[ *`t1 t2`* ... \]
|
||||
|
||||
: Type *`t1`* or type *`t2`* and so forth, e.g.
|
||||
`with types; oneOf [ int str bool ]`. Multiple definitions cannot be
|
||||
|
|
|
@ -24,7 +24,7 @@ can be declared. File formats can be separated into two categories:
|
|||
an `extraConfig` option of type `lines` to allow arbitrary text
|
||||
after the autogenerated part of the file.
|
||||
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, \...) {#sec-settings-nix-representable}
|
||||
## Nix-representable Formats (JSON, YAML, TOML, INI, ...) {#sec-settings-nix-representable}
|
||||
|
||||
By convention, formats like this are handled with a generic `settings`
|
||||
option, representing the full program configuration as a Nix value. The
|
||||
|
|
|
@ -352,7 +352,7 @@ services.xserver.extraLayouts.media = {
|
|||
<para>
|
||||
Unfortunately, the Xorg server does not (currently) support
|
||||
setting a keymap directly but relies instead on XKB rules to
|
||||
select the matching components (keycodes, types, ...) of a layout.
|
||||
select the matching components (keycodes, types, …) of a layout.
|
||||
This means that components other than symbols won’t be loaded by
|
||||
default. As a workaround, you can set the keymap using
|
||||
<literal>setxkbmap</literal> at the start of the session with:
|
||||
|
|
|
@ -222,7 +222,7 @@ lib.mkOption {
|
|||
As an example, we will take the case of display managers.
|
||||
There is a central display manager module for generic
|
||||
display manager options and a module file per display
|
||||
manager backend (sddm, gdm ...).
|
||||
manager backend (sddm, gdm …).
|
||||
</para>
|
||||
<para>
|
||||
There are two approaches we could take with this module
|
||||
|
|
|
@ -668,7 +668,7 @@
|
|||
<varlistentry>
|
||||
<term>
|
||||
<literal>types.oneOf</literal> [
|
||||
<emphasis><literal>t1 t2</literal></emphasis> ... ]
|
||||
<emphasis><literal>t1 t2</literal></emphasis> … ]
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
|
|
|
@ -42,8 +42,7 @@
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="sec-settings-nix-representable">
|
||||
<title>Nix-representable Formats (JSON, YAML, TOML, INI,
|
||||
...)</title>
|
||||
<title>Nix-representable Formats (JSON, YAML, TOML, INI, …)</title>
|
||||
<para>
|
||||
By convention, formats like this are handled with a generic
|
||||
<literal>settings</literal> option, representing the full program
|
||||
|
|
Loading…
Reference in a new issue