doc/using/overrides: Relate addition to preceding text

1 files changed, 3 insertions, 1 deletions

diff --git a/doc/using/overrides.chapter.md b/doc/using/overrides.chapter.md
index 060bf051b929b..a1ef9afb0b69d 100644
--- a/doc/using/overrides.chapter.md
+++ b/doc/using/overrides.chapter.md
@@ -58,13 +58,15 @@ The argument `finalAttrs` refers to the final attributes passed to `mkDerivation
 
 If only a one-argument function is written, the argument has the meaning of `previousAttrs`.
 
+Function arguments can be omitted entirely if there is no need to access `previousAttrs` or `finalAttrs`.
+
 ```nix
 helloWithDebug = pkgs.hello.overrideAttrs {
   separateDebugInfo = true;
 };
 ```
 
-In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`. Function arguments can be omitted if there is no need to access previousAttrs or finalAttrs.
+In the above example, the `separateDebugInfo` attribute is overridden to be true, thus building debug info for `helloWithDebug`.
 
 ::: {.note}
 Note that `separateDebugInfo` is processed only by the `stdenv.mkDerivation` function, not the generated, raw Nix derivation. Thus, using `overrideDerivation` will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that `overrideAttrs` should be preferred in (almost) all cases to `overrideDerivation`, i.e. to allow using `stdenv.mkDerivation` to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. `buildInputs` vs `nativeBuildInputs`), and it involves less typing).