doc/*: editorconfig fixes

zowoq b3d71cd6 af2055de

+14 -15
+1 -1
doc/builders/packages/urxvt.xml
··· 50 50 In addition to <literal>plugins</literal> the options 51 51 <literal>extraDeps</literal> and <literal>perlDeps</literal> can be used 52 52 to install extra packages. 53 - <literal>extraDeps</literal> can be used, for example, to provide 53 + <literal>extraDeps</literal> can be used, for example, to provide 54 54 <literal>xsel</literal> (a clipboard manager) to the clipboard plugin, 55 55 without installing it globally: 56 56 <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {
+1 -1
doc/languages-frameworks/beam.xml
··· 68 68 <title>How to Install BEAM Packages</title> 69 69 70 70 <para> 71 - BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. 71 + BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. 72 72 To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>: 73 73 </para> 74 74
+8 -9
doc/languages-frameworks/emscripten.section.md
··· 21 21 * **Declarative usage**: 22 22 23 23 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`. 24 - * build and install all packages: 25 - * `nix-env -iA emscriptenPackages` 26 - 27 - * dev-shell for zlib implementation hacking: 28 - * `nix-shell -A emscriptenPackages.zlib` 24 + * build and install all packages: 25 + * `nix-env -iA emscriptenPackages` 26 + 27 + * dev-shell for zlib implementation hacking: 28 + * `nix-shell -A emscriptenPackages.zlib` 29 29 30 30 31 31 ## Imperative usage ··· 90 90 libz.so.${old.version} -I . -o example.js 91 91 92 92 echo "Using node to execute the test" 93 - ${pkgs.nodejs}/bin/node ./example.js 93 + ${pkgs.nodejs}/bin/node ./example.js 94 94 95 95 set +x 96 96 if [ $? -ne 0 ]; then ··· 112 112 113 113 ### Usage 2: pkgs.buildEmscriptenPackage 114 114 115 - This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used. 115 + This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used. 116 116 117 117 xmlmirror = pkgs.buildEmscriptenPackage rec { 118 118 name = "xmlmirror"; ··· 163 163 checkPhase = '' 164 164 165 165 ''; 166 - }; 166 + }; 167 167 168 168 ### Declarative debugging 169 169 ··· 182 182 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. 183 183 184 184 If in trouble, ask the maintainers. 185 -
+1 -1
doc/languages-frameworks/go.xml
··· 72 72 73 73 When `null` is used as a value, rather than fetching the dependencies 74 74 and vendoring them, we use the vendoring included within the source repo. 75 - If you'd like to not have to update this field on dependency changes, 75 + If you'd like to not have to update this field on dependency changes, 76 76 run `go mod vendor` in your source repo and set 'vendorSha256 = null;' 77 77 </para> 78 78 </section>
+1 -1
doc/languages-frameworks/rust.section.md
··· 79 79 80 80 When using `buildRustPackage`, the `checkPhase` is enabled by default and runs 81 81 `cargo test` on the package to build. To make sure that we don't compile the 82 - sources twice and to actually test the artifacts that will be used at runtime, 82 + sources twice and to actually test the artifacts that will be used at runtime, 83 83 the tests will be ran in the `release` mode by default. 84 84 85 85 However, in some cases the test-suite of a package doesn't work properly in the
+2 -2
doc/old/cross.txt
··· 220 220 221 221 preConfigure=preConfigure 222 222 preConfigure() { 223 - 223 + 224 224 # Determine the frontends to build. 225 225 langs="c" 226 226 if test -n "$langCC"; then ··· 262 262 263 263 #if test -z "$profiledCompiler"; then 264 264 #makeFlags="bootstrap" 265 - #else 265 + #else 266 266 #makeFlags="profiledbootstrap" 267 267 #fi 268 268