**/README.md: one sentence per line

As documented in doc/README.md.

Author: wolfgangwalther

CONTRIBUTING.md

@@ -13,10 +13,8 @@
   <a href="https://opencollective.com/nixos"><img src="https://opencollective.com/nixos/tiers/supporter/badge.svg?label=supporters&color=brightgreen" alt="Open Collective supporters" /></a>
 </p>
 
-[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over
-120,000 software packages that can be installed with the
-[Nix](https://nixos.org/nix/) package manager. It also implements
-[NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
+[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over 120,000 software packages that can be installed with the [Nix](https://nixos.org/nix/) package manager.
+It also implements [NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
 
 # Manuals
 
@@ -34,9 +32,8 @@
 
 # Other Project Repositories
 
-The sources of all official Nix-related projects are in the [NixOS
-organization on GitHub](https://github.com/NixOS/). Here are some of
-the main ones:
+The sources of all official Nix-related projects are in the [NixOS organization on GitHub](https://github.com/NixOS/).
+Here are some of the main ones:
 
 * [Nix](https://github.com/NixOS/nix) - the purely functional package manager
 * [NixOps](https://github.com/NixOS/nixops) - the tool to remotely deploy NixOS machines
@@ -48,54 +45,41 @@ the main ones:
 
 # Continuous Integration and Distribution
 
-Nixpkgs and NixOS are built and tested by our continuous integration
-system, [Hydra](https://hydra.nixos.org/).
+Nixpkgs and NixOS are built and tested by our continuous integration system, [Hydra](https://hydra.nixos.org/).
 
 * [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
 * [Continuous package builds for the NixOS 25.05 release](https://hydra.nixos.org/jobset/nixos/release-25.05)
 * [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
 * [Tests for the NixOS 25.05 release](https://hydra.nixos.org/job/nixos/release-25.05/tested#tabs-constituents)
 
-Artifacts successfully built with Hydra are published to cache at
-https://cache.nixos.org/. When successful build and test criteria are
-met, the Nixpkgs expressions are distributed via [Nix
-channels](https://nix.dev/manual/nix/stable/command-ref/nix-channel.html).
+Artifacts successfully built with Hydra are published to cache at https://cache.nixos.org/.
+When successful build and test criteria are met, the Nixpkgs expressions are distributed via [Nix channels](https://nix.dev/manual/nix/stable/command-ref/nix-channel.html).
 
 # Contributing
 
-Nixpkgs is among the most active projects on GitHub. While thousands
-of open issues and pull requests might seem a lot at first, it helps
-consider it in the context of the scope of the project. Nixpkgs
-describes how to build tens of thousands of pieces of software and implements a
-Linux distribution. The [GitHub Insights](https://github.com/NixOS/nixpkgs/pulse)
-page gives a sense of the project activity.
+Nixpkgs is among the most active projects on GitHub.
+While thousands of open issues and pull requests might seem a lot at first, it helps consider it in the context of the scope of the project.
+Nixpkgs describes how to build tens of thousands of pieces of software and implements a Linux distribution.
+The [GitHub Insights](https://github.com/NixOS/nixpkgs/pulse) page gives a sense of the project activity.
 
-Community contributions are always welcome through GitHub Issues and
-Pull Requests.
+Community contributions are always welcome through GitHub Issues and Pull Requests.
 
-For more information about contributing to the project, please visit
-the [contributing page](CONTRIBUTING.md).
+For more information about contributing to the project, please visit the [contributing page](CONTRIBUTING.md).
 
 # Donations
 
-The infrastructure for NixOS and related projects is maintained by a
-nonprofit organization, the [NixOS
-Foundation](https://nixos.org/nixos/foundation.html). To ensure the
-continuity and expansion of the NixOS infrastructure, we are looking
-for donations to our organization.
+The infrastructure for NixOS and related projects is maintained by a nonprofit organization, the [NixOS Foundation](https://nixos.org/nixos/foundation.html).
+To ensure the continuity and expansion of the NixOS infrastructure, we are looking for donations to our organization.
 
-You can donate to the NixOS foundation through [SEPA bank
-transfers](https://nixos.org/donate.html) or by using Open Collective:
+You can donate to the NixOS foundation through [SEPA bank transfers](https://nixos.org/donate.html) or by using Open Collective:
 
 <a href="https://opencollective.com/nixos#support"><img src="https://opencollective.com/nixos/tiers/supporter.svg?width=890" /></a>
 
 # License
 
 Nixpkgs is licensed under the [MIT License](COPYING).
 
-Note: MIT license does not apply to the packages built by Nixpkgs,
-merely to the files in this repository (the Nix expressions, build
-scripts, NixOS modules, etc.). It also might not apply to patches
-included in Nixpkgs, which may be derivative works of the packages to
-which they apply. The aforementioned artifacts are all covered by the
-licenses of the respective packages.
+Note:
+MIT license does not apply to the packages built by Nixpkgs, merely to the files in this repository (the Nix expressions, build scripts, NixOS modules, etc.).
+It also might not apply to patches included in Nixpkgs, which may be derivative works of the packages to which they apply.
+The aforementioned artifacts are all covered by the licenses of the respective packages.

README.md

@@ -62,21 +62,24 @@ Use [`devmode`](../pkgs/by-name/de/devmode/README.md) for a live preview when ed
 
 Once you have a successful build, you can open the relevant HTML (path mentioned above) in a browser along with the anchor, and observe the redirection.
 
-Note that if you already loaded the page and *then* input the anchor, you will need to perform a reload. This is because browsers do not re-run client JS code when only the anchor has changed.
+Note that if you already loaded the page and *then* input the anchor, you will need to perform a reload.
+This is because browsers do not re-run client JS code when only the anchor has changed.
 
 ## Syntax
 
 As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
 
-Additional syntax extensions are available, all of which can be used in NixOS option documentation. The following extensions are currently used:
+Additional syntax extensions are available, all of which can be used in NixOS option documentation.
+The following extensions are currently used:
 
 #### Tables
 
 Tables, using the [GitHub-flavored Markdown syntax](https://github.github.com/gfm/#tables-extension-).
 
 #### Anchors
 
-Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
+Explicitly defined **anchors** on headings, to allow linking to sections.
+These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
 
 It uses the widely compatible [header attributes](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/attributes.md) syntax:
 
@@ -99,18 +102,21 @@ They are defined using a hybrid of the link syntax with the attributes syntax kn
 
 #### Automatic links
 
-If you **omit a link text** for a link pointing to a section, the text will be substituted automatically. For example `[](#chap-contributing)`.
+If you **omit a link text** for a link pointing to a section, the text will be substituted automatically.
+For example `[](#chap-contributing)`.
 
 This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
 
 
 #### HTML
 
-Inlining HTML is not allowed. Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
+Inlining HTML is not allowed.
+Parts of the documentation gets rendered to various non-HTML formats, such as man pages in the case of NixOS manual.
 
 #### Roles
 
-If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``. The references will turn into links when a mapping exists in [`doc/manpage-urls.json`](./manpage-urls.json).
+If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``.
+The references will turn into links when a mapping exists in [`doc/manpage-urls.json`](./manpage-urls.json).
 Please keep the `manpage-urls.json` file alphabetically sorted.
 
 A few markups for other kinds of literals are also available:
@@ -123,7 +129,8 @@ A few markups for other kinds of literals are also available:
 
 These literal kinds are used mostly in NixOS option documentation.
 
-This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
+This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point).
+Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
 They are handled by `myst_role` defined per renderer. <!-- reverse references in code -->
 
 #### Admonitions
@@ -326,8 +333,11 @@ Otherwise, just describe the single argument or start the arguments' definition
 
 Checklist:
 - Start with a synopsis, to show the order of positional arguments.
-- Metavariables are in emphasized code spans: ``` *`arg1`* ```. Metavariables are placeholders where users may write arbitrary expressions. This includes positional arguments.
-- Attribute names are regular code spans: ``` `attr1` ```. These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
+- Metavariables are in emphasized code spans: ``` *`arg1`* ```.
+  Metavariables are placeholders where users may write arbitrary expressions.
+  This includes positional arguments.
+- Attribute names are regular code spans: ``` `attr1` ```.
+  These identifiers can _not_ be picked freely by users, so they are _not_ metavariables.
 - _optional_ attributes have a _`Default:`_ if it's easily described as a value.
 - _optional_ attributes have a _`Default behavior:`_ if it's not easily described using a value.
 - Nix types aren't in code spans, because they are not code
@@ -404,7 +414,8 @@ This syntax is taken from [CommonMark](https://spec.commonmark.org/0.30/#link-re
 
 #### Typographic replacements
 
-Typographic replacements are enabled. Check the [list of possible replacement patterns check](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
+Typographic replacements are enabled.
+Check the [list of possible replacement patterns check](https://github.com/executablebooks/markdown-it-py/blob/3613e8016ecafe21709471ee0032a90a4157c2d1/markdown_it/rules_core/replacements.py#L1-L15).
 
 ## Getting help
 

doc/README.md

@@ -4,8 +4,7 @@
 Do not add any new functions to this directory.
 
 This directory contains the `lib.misc` sublibrary, which - as a location - is deprecated.
-Furthermore, some of the functions inside are of *dubious* utility, and should perhaps be avoided,
-while some functions *may still be needed*.
+Furthermore, some of the functions inside are of *dubious* utility, and should perhaps be avoided, while some functions *may still be needed*.
 
 This directory does not play a role in the deprecation process for library functions.
 They should be deprecated in place, by putting a `lib.warn` or `lib.warnIf` call around the function.

lib/deprecated/README.md

@@ -166,7 +166,8 @@ Meanwhile `intersection ./foo ./bar` returns the empty file set without a base p
 
 Arguments:
 - Alternative: Use the common prefix of all base paths as the resulting base path
-  - (-) This is unnecessarily strict, because the purpose of the base path is to track the directory under which files _could_ be in the file set. It should be as long as possible.
+  - (-) This is unnecessarily strict, because the purpose of the base path is to track the directory under which files _could_ be in the file set.
+    It should be as long as possible.
     All files contained in `intersection ./foo ./foo/bar` will be under `./foo/bar` (never just under `./foo`), and `intersection ./foo ./bar` will never contain any files (never under `./.`).
     This would lead to `toSource` having to unexpectedly throw errors for cases such as `toSource { root = ./foo; fileset = intersect ./foo base; }`, where `base` may be `./bar` or `./.`.
   - (-) There is no benefit to the user, since base path is not directly exposed in the interface
@@ -263,5 +264,6 @@ Coercing paths that don't exist to file sets always gives an error.
   - (+) This is dangerous, because you wouldn't be protected against typos anymore.
     E.g. when trying to prevent `./secret` from being imported, a typo like `difference ./. ./sercet` would import it regardless.
   - (+) `difference ./. (maybeMissing ./does-not-exist)` can be used to do this more explicitly.
-  - (+) `difference ./. (difference ./foo ./foo/bar)` should report an error when `./foo/bar` does not exist ("double negation"). Unfortunately, the current internal representation does not lend itself to a behavior where both `difference x ./does-not-exists` and double negation are handled and checked correctly.
+  - (+) `difference ./. (difference ./foo ./foo/bar)` should report an error when `./foo/bar` does not exist ("double negation").
+    Unfortunately, the current internal representation does not lend itself to a behavior where both `difference x ./does-not-exists` and double negation are handled and checked correctly.
     This could be fixed, but would require significant changes to the internal representation that are not worth the effort and the risk of introducing implicit behavior.