Linting

doc.zih.tu-dresden.de/docs/software/modules.md

@@ -148,9 +148,9 @@ There is a front end for the module command, which helps you to type less. It is
 
 ## Module Environments
 
-On ZIH systems, there exist different **module environments**, each containing a set of software modules.
-They are activated via the meta module `modenv` which has different versions, one of which is loaded
-by default. You can switch between them by simply loading the desired modenv-version, e.g.
+On ZIH systems, there exist different **module environments**, each containing a set of software
+modules.  They are activated via the meta module `modenv` which has different versions, one of which
+is loaded by default. You can switch between them by simply loading the desired modenv-version, e.g.
 
 ```console
 marie@compute$ module load modenv/ml
@@ -183,8 +183,8 @@ Thus the 'machine code' of other modenvs breaks).
 ### Searching for Software
 
 The command `module spider <modname>` allows searching for a specific software across all modenv
-environments. It will also display information on how to load a particular module when giving a precise
-module (with version) as the parameter.
+environments. It will also display information on how to load a particular module when giving a
+precise module (with version) as the parameter.
 
 ??? example "Spider command"
 
@@ -259,18 +259,16 @@ In some cases a desired software is available as an extension of a module.
 
 ## Toolchains
 
-A program or library may break in various ways
-(e.g. not starting, crashing or producing wrong results)
-when it is used with a software of a different version than it expects.  
-So each module specifies the exact other modules it depends on.
-They get loaded automatically when the dependent module is loaded.
+A program or library may break in various ways (e.g. not starting, crashing or producing wrong
+results) when it is used with a software of a different version than it expects. So each module
+specifies the exact other modules it depends on. They get loaded automatically when the dependent
+module is loaded.
 
-Loading a single module is easy as there can't be any conflicts between dependencies.
-However when loading multiple modules they can require different versions of the same software.
-This conflict is currently handled in that loading the same software with a different version
-automatically unloads the earlier loaded module.
-As the dependents of that module are **not** automatically unloaded this means they now have a
-wrong dependency (version) which can be a problem (see above).
+Loading a single module is easy as there can't be any conflicts between dependencies. However when
+loading multiple modules they can require different versions of the same software. This conflict is
+currently handled in that loading the same software with a different version automatically unloads
+the earlier loaded module.  As the dependents of that module are **not** automatically unloaded this
+means they now have a wrong dependency (version) which can be a problem (see above).
 
 To avoid this there are (versioned) toolchains and for each toolchain there is (usually) at most
 one version of each software.
@@ -309,12 +307,12 @@ As you can see `GCC` and `intel-compilers` are on the same level, as are `gompi`
 although they are one level higher than the former.
 
 You can load and use modules from a lower toolchain with modules from
-one of its parent toolchains.  
+one of its parent toolchains.
 For example `Python/3.6.6-foss-2019a` can be used with `Boost/1.70.0-gompi-2019a`.
 
 But you cannot combine toolchains or toolchain versions.
 So `QuantumESPRESSO/6.5-intel-2019a` and `OpenFOAM/8-foss-2020a`
-are both incompatible with `Python/3.6.6-foss-2019a`.  
+are both incompatible with `Python/3.6.6-foss-2019a`.
 However `LLVM/7.0.1-GCCcore-8.2.0` can be used with either
 `QuantumESPRESSO/6.5-intel-2019a` or `Python/3.6.6-foss-2019a`
 because `GCCcore-8.2.0` is a sub-toolchain of `intel-2019a` and `foss-2019a`.