Re-wrap and re-format some docs to make the LaTeX friendly

doc/05-repositories.md

@@ -229,21 +229,32 @@ In this case the short name of the channel is `pear2`, so the
 > package, so this may considerably slow down the installation process.
 
 #### Custom channel alias
+
 It is possible to alias all pear channel packages with custom name.
 
 Example:
-You own private pear repository and going to use composer abilities to bring dependencies from vcs or transit to composer repository scheme.
-Your repository list of packages:
+
+You own private pear repository and going to use composer abilities to bring
+dependencies from vcs or transit to composer repository scheme. Your
+repository list of packages:
+
  * BasePackage, requires nothing
  * IntermediatePackage, depends on BasePackage
  * TopLevelPackage1 and TopLevelPackage2 both dependth on IntermediatePackage.
 
 For composer it looks like:
+
  * "pear-pear.foobar.repo/IntermediatePackage" depends on "pear-pear.foobar.repo/BasePackage",
  * "pear-pear.foobar.repo/TopLevelPackage1" depends on "pear-pear.foobar.repo/IntermediatePackage",
  * "pear-pear.foobar.repo/TopLevelPackage2" depends on "pear-pear.foobar.repo/IntermediatePackage"
 
-When you update one of your packages to composer naming scheme or made it available through vcs, your older dependencies would not see new version, cause it would be named like "foobar/IntermediatePackage". Specifying 'vendor-alias' for pear repository, you will get all its packages aliased with composer-like names. Following example would take BasePackage, TopLevelPackage1 and TopLevelPackage2 packages from pear repository and IntermediatePackage from github repository:
+When you update one of your packages to composer naming scheme or made it
+available through vcs, your older dependencies would not see new version,
+cause it would be named like "foobar/IntermediatePackage". Specifying 'vendor-
+alias' for pear repository, you will get all its packages aliased with
+composer-like names. Following example would take BasePackage,
+TopLevelPackage1 and TopLevelPackage2 packages from pear repository and
+IntermediatePackage from github repository:
 
     {
         "repositories": [

doc/articles/aliases.md

@@ -1,6 +1,7 @@
 <!--
     tagline: Alias branch names to versions
 -->
+
 # Aliases
 
 ## Why aliases?

doc/articles/custom-installers.md

@@ -1,6 +1,7 @@
 <!--
     tagline: Modify the way certain types of packages are installed
 -->
+
 # Setting up and using custom installers
 
 ## Synopsis
@@ -48,15 +49,15 @@ An example composer.json of such a template package would be:
 ## Creating an Installer
 
 A Custom Installer is defined as a class that implements the
-[\Composer\Installer\InstallerInterface][3] and is contained in a Composer
+[`Composer\Installer\InstallerInterface`][3] and is contained in a Composer
 package that has the [type][1] `composer-installer`.
 
 A basic Installer would thus compose of two files:
 
 1. the package file: composer.json
-2. The Installer class, i.e.: \Composer\Installer\MyInstaller.php
+2. The Installer class, i.e.: `Composer\Installer\MyInstaller.php`
 
-> **NOTE**: _The namespace does not need to be \Composer\Installer, it must
+> **NOTE**: _The namespace does not need to be `Composer\Installer`, it must
 > only implement the right interface._
 
 ### composer.json
@@ -86,7 +87,7 @@ Example:
 ### The Custom Installer class
 
 The class that executes the custom installation should implement the
-[\Composer\Installer\InstallerInterface][3] (or extend another installer that
+[`Composer\Installer\InstallerInterface`][3] (or extend another installer that
 implements that interface).
 
 The class may be placed in any location and have any name, as long as it is
@@ -148,7 +149,7 @@ Example:
     }
 
 The example demonstrates that it is quite simple to extend the
-[\Composer\Installer\LibraryInstaller][4] class to strip a prefix
+[`Composer\Installer\LibraryInstaller`][4] class to strip a prefix
 (`phpdocumentor/template-`) and use the remaining part to assemble a completely
 different installation path.
 

doc/articles/handling-private-packages-with-satis.md

@@ -1,6 +1,7 @@
 <!--
     tagline: Host your own composer repository
 -->
+
 # Handling private packages with Satis
 
 Satis can be used to host the metadata of your company's private packages, or

doc/articles/scripts.md

@@ -1,6 +1,7 @@
 <!--
     tagline: Script are callbacks that are called before/after installing packages
 -->
+
 # Scripts
 
 ## What is a script?

doc/articles/vendor-bins.md

@@ -1,6 +1,7 @@
 <!--
     tagline: Expose command-line scripts from packages
 -->
+
 # bin and vendor/bin
 
 ## What is a bin?