doc/*: editorconfig fixes

doc/builders/packages/urxvt.xml

@@ -50,7 +50,7 @@ map (p: p.name) pkgs.rxvt-unicode.plugins
     In addition to <literal>plugins</literal> the options
     <literal>extraDeps</literal> and <literal>perlDeps</literal> can be used
     to install extra packages.
-    <literal>extraDeps</literal> can be used, for example, to provide 
+    <literal>extraDeps</literal> can be used, for example, to provide
     <literal>xsel</literal> (a clipboard manager) to the clipboard plugin,
     without installing it globally:
     <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {

doc/languages-frameworks/beam.xml

@@ -68,7 +68,7 @@
   <title>How to Install BEAM Packages</title>
 
   <para>
-   BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. 
+   BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.
    To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:
   </para>
 

doc/languages-frameworks/emscripten.section.md

@@ -21,11 +21,11 @@ Modes of use of `emscripten`:
 * **Declarative usage**:
 
     This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.
-    * build and install all packages: 
-        * `nix-env -iA emscriptenPackages` 
-          
-    * dev-shell for zlib implementation hacking: 
-        * `nix-shell -A emscriptenPackages.zlib` 
+    * build and install all packages:
+        * `nix-env -iA emscriptenPackages`
+
+    * dev-shell for zlib implementation hacking:
+        * `nix-shell -A emscriptenPackages.zlib`
 
 
 ## Imperative usage
@@ -90,7 +90,7 @@ See the `zlib` example:
         libz.so.${old.version} -I . -o example.js
 
         echo "Using node to execute the test"
-        ${pkgs.nodejs}/bin/node ./example.js 
+        ${pkgs.nodejs}/bin/node ./example.js
 
         set +x
         if [ $? -ne 0 ]; then
@@ -112,7 +112,7 @@ See the `zlib` example:
 
 ### Usage 2: pkgs.buildEmscriptenPackage
 
-This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used. 
+This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
 
     xmlmirror = pkgs.buildEmscriptenPackage rec {
       name = "xmlmirror";
@@ -163,7 +163,7 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
       checkPhase = ''
 
       '';
-    }; 
+    };
 
 ### Declarative debugging
 
@@ -182,4 +182,3 @@ Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from
 Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.
 
 If in trouble, ask the maintainers.
-

doc/languages-frameworks/go.xml

@@ -72,7 +72,7 @@ pet = buildGoModule rec {
 
     When `null` is used as a value, rather than fetching the dependencies
     and vendoring them, we use the vendoring included within the source repo.
-    If you'd like to not have to update this field on dependency changes, 
+    If you'd like to not have to update this field on dependency changes,
     run `go mod vendor` in your source repo and set 'vendorSha256 = null;'
   </para>
  </section>

doc/languages-frameworks/rust.section.md

@@ -79,7 +79,7 @@ pkgs.rustPlatform.buildRustPackage {
 
 When using `buildRustPackage`, the `checkPhase` is enabled by default and runs
 `cargo test` on the package to build. To make sure that we don't compile the
-sources twice and to actually test the artifacts that will be used at runtime, 
+sources twice and to actually test the artifacts that will be used at runtime,
 the tests will be ran in the `release` mode by default.
 
 However, in some cases the test-suite of a package doesn't work properly in the

doc/old/cross.txt

@@ -220,7 +220,7 @@ fi
 
 preConfigure=preConfigure
 preConfigure() {
-    
+
     # Determine the frontends to build.
     langs="c"
     if test -n "$langCC"; then
@@ -262,7 +262,7 @@ postInstall() {
 
 #if test -z "$profiledCompiler"; then
     #makeFlags="bootstrap"
-#else    
+#else
     #makeFlags="profiledbootstrap"
 #fi