Remove fenced blocks in docs

doc/00-intro.md

@@ -26,13 +26,11 @@ You decide to use [monolog](https://github.com/Seldaek/monolog). In order to
 add it to your project, all you need to do is create a `composer.json` file
 which describes the project's dependencies.
 
-```json
-{
-    "require": {
-        "monolog/monolog": "1.0.*"
+    {
+        "require": {
+            "monolog/monolog": "1.0.*"
+        }
     }
-}
-```
 
 We are simply stating that our project requires the `monolog/monolog` package,
 any version beginning with `1.0`.
@@ -58,8 +56,6 @@ This will download monolog and dump it into `vendor/monolog/monolog`.
 After this you can just add the following line to your bootstrap code to get
 autoloading:
 
-```php
-require 'vendor/.composer/autoload.php';
-```
+    require 'vendor/.composer/autoload.php';
 
 That's all it takes to have a basic setup.

doc/01-basic-usage.md

@@ -42,13 +42,11 @@ The first (and often only) thing you specify in `composer.json` is the
 `require` key. You're simply telling composer which packages your project
 depends on.
 
-```json
-{
-    "require": {
-        "monolog/monolog": "1.0.*"
+    {
+        "require": {
+            "monolog/monolog": "1.0.*"
+        }
     }
-}
-```
 
 As you can see, `require` takes an object that maps package names to versions.
 
@@ -141,32 +139,26 @@ naming standard, composer generates a
 `vendor/.composer/autoload.php` file for autoloading. You can simply include
 this file and you will get autoloading for free.
 
-```php
-require 'vendor/.composer/autoload.php';
-```
+    require 'vendor/.composer/autoload.php';
 
 This makes it really easy to use third party code, because you only
 have to add one line to `composer.json` and run `install`. For monolog, it
 means that we can just start using classes from it, and they will be
 autoloaded.
 
-```php
-$log = new Monolog\Logger('name');
-$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Logger::WARNING));
+    $log = new Monolog\Logger('name');
+    $log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Logger::WARNING));
 
-$log->addWarning('Foo');
-```
+    $log->addWarning('Foo');
 
 You can even add your own code to the autoloader by adding an `autoload` field
 to `composer.json`.
 
-```json
-{
-    "autoload": {
-        "psr-0": {"Acme": "src/"}
+    {
+        "autoload": {
+            "psr-0": {"Acme": "src/"}
+        }
     }
-}
-```
 
 This is a mapping from namespaces to directories. The `src` directory would be
 in your project root. An example filename would be `src/Acme/Foo.php`
@@ -179,10 +171,8 @@ Including that file will also return the autoloader instance, so you can store
 the return value of the include call in a variable and add more namespaces.
 This can be useful for autoloading classes in a test suite, for example.
 
-```php
-$loader = require 'vendor/.composer/autoload.php';
-$loader->add('Acme\Test', __DIR__);
-```
+    $loader = require 'vendor/.composer/autoload.php';
+    $loader->add('Acme\Test', __DIR__);
 
 > **Note:** Composer provides its own autoloader. If you don't want to use
 that one, you can just include `vendor/.composer/autoload_namespaces.php`,

doc/02-libraries.md

@@ -12,14 +12,12 @@ libraries is that your project is a package without a name.
 In order to make that package installable you need to give it a name. You do
 this by adding a `name` to `composer.json`:
 
-```json
-{
-    "name": "acme/hello-world",
-    "require": {
-        "monolog/monolog": "1.0.*"
+    {
+        "name": "acme/hello-world",
+        "require": {
+            "monolog/monolog": "1.0.*"
+        }
     }
-}
-```
 
 In this case the project name is `acme/hello-world`, where `acme` is the
 vendor name. Supplying a vendor name is mandatory.
@@ -36,11 +34,9 @@ the repository is able to infer the version from elsewhere.
 
 If you do want to specify it explicitly, you can just add a `version` field:
 
-```json
-{
-    "version": "1.0.0"
-}
-```
+    {
+        "version": "1.0.0"
+    }
 
 However if you are using git, svn or hg, you don't have to specify it.
 Composer will detect versions as follows:
@@ -105,14 +101,12 @@ project locally. We will call it `acme/blog`. This blog will depend on `acme
 this by creating a new `blog` directory somewhere, containing a
 `composer.json`:
 
-```json
-{
-    "name": "acme/blog",
-    "require": {
-        "acme/hello-world": "dev-master"
+    {
+        "name": "acme/blog",
+        "require": {
+            "acme/hello-world": "dev-master"
+        }
     }
-}
-```
 
 The name is not needed in this case, since we don't want to publish the blog
 as a library. It is added here to clarify which `composer.json` is being
@@ -122,19 +116,17 @@ Now we need to tell the blog app where to find the `hello-world` dependency.
 We do this by adding a package repository specification to the blog's
 `composer.json`:
 
-```json
-{
-    "name": "acme/blog",
-    "repositories": {
-        "acme/hello-world": {
-            "vcs": { "url": "https://github.com/composer/hello-world" }
+    {
+        "name": "acme/blog",
+        "repositories": {
+            "acme/hello-world": {
+                "vcs": { "url": "https://github.com/composer/hello-world" }
+            }
+        },
+        "require": {
+            "acme/hello-world": "dev-master"
         }
-    },
-    "require": {
-        "acme/hello-world": "dev-master"
     }
-}
-```
 
 For more details on how package repositories work and what other types are
 available, see [Repositories].

doc/04-schema.md

@@ -134,22 +134,20 @@ Each author object can have following properties:
 
 An example:
 
-```json
-{
-    "authors": [
-        {
-            "name": "Nils Adermann",
-            "email": "naderman@naderman.de",
-            "homepage": "http://www.naderman.de"
-        },
-        {
-            "name": "Jordi Boggiano",
-            "email": "j.boggiano@seld.be",
-            "homepage": "http://seld.be"
-        }
-    ]
-}
-```
+    {
+        "authors": [
+            {
+                "name": "Nils Adermann",
+                "email": "naderman@naderman.de",
+                "homepage": "http://www.naderman.de"
+            },
+            {
+                "name": "Jordi Boggiano",
+                "email": "j.boggiano@seld.be",
+                "homepage": "http://seld.be"
+            }
+        ]
+    }
 
 Optional, but highly recommended.
 
@@ -173,13 +171,11 @@ Each of these takes an object which maps package names to version constraints.
 
 Example:
 
-```json
-{
-    "require": {
-        "monolog/monolog": "1.0.*"
+    {
+        "require": {
+            "monolog/monolog": "1.0.*"
+        }
     }
-}
-```
 
 Optional.
 
@@ -194,13 +190,11 @@ package root.
 
 Example:
 
-```json
-{
-    "autoload": {
-        "psr-0": { "Monolog": "src/" }
+    {
+        "autoload": {
+            "psr-0": { "Monolog": "src/" }
+        }
     }
-}
-```
 
 Optional, but it is highly recommended that you follow PSR-0 and use this.
 
@@ -220,14 +214,12 @@ it from `vendor/symfony/yaml`.
 
 To do that, `autoload` and `target-dir` are defined as follows:
 
-```json
-{
-    "autoload": {
-        "psr-0": { "Symfony\\Component\\Yaml": "" }
-    },
-    "target-dir": "Symfony/Component/Yaml"
-}
-```
+    {
+        "autoload": {
+            "psr-0": { "Symfony\\Component\\Yaml": "" }
+        },
+        "target-dir": "Symfony/Component/Yaml"
+    }
 
 Optional.
 
@@ -259,40 +251,38 @@ For more information on any of these, see [Repositories].
 
 Example:
 
-```json
-{
-    "repositories": [
-        {
-            "type": "composer",
-            "url": "http://packages.example.com"
-        },
-        {
-            "type": "vcs",
-            "url": "https://github.com/Seldaek/monolog"
-        },
-        {
-            "type": "pear",
-            "url": "http://pear2.php.net"
-        },
-        {
-            "type": "package",
-            "package": {
-                "name": "smarty/smarty",
-                "version": "3.1.7",
-                "dist": {
-                    "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
-                    "type": "zip"
-                },
-                "source": {
-                    "url": "http://smarty-php.googlecode.com/svn/",
-                    "type": "svn",
-                    "reference": "tags/Smarty_3_1_7/distribution/"
+    {
+        "repositories": [
+            {
+                "type": "composer",
+                "url": "http://packages.example.com"
+            },
+            {
+                "type": "vcs",
+                "url": "https://github.com/Seldaek/monolog"
+            },
+            {
+                "type": "pear",
+                "url": "http://pear2.php.net"
+            },
+            {
+                "type": "package",
+                "package": {
+                    "name": "smarty/smarty",
+                    "version": "3.1.7",
+                    "dist": {
+                        "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
+                        "type": "zip"
+                    },
+                    "source": {
+                        "url": "http://smarty-php.googlecode.com/svn/",
+                        "type": "svn",
+                        "reference": "tags/Smarty_3_1_7/distribution/"
+                    }
                 }
             }
-        }
-    ]
-}
-```
+        ]
+    }
 
 > **Note:** Order is significant here. Repositories added later will take
 precedence. This also means that custom repositories can override packages
@@ -301,15 +291,13 @@ that exist on packagist.
 You can also disable the packagist repository by setting `packagist` to
 `false`.
 
-```json
-{
-    "repositories": [
-        {
-            "packagist": false
-        }
-    ]
-}
-```
+    {
+        "repositories": [
+            {
+                "packagist": false
+            }
+        ]
+    }
 
 ## config
 
@@ -327,13 +315,11 @@ The following options are supported:
 
 Example:
 
-```json
-{
-    "config": {
-        "bin-dir": "bin"
+    {
+        "config": {
+            "bin-dir": "bin"
+        }
     }
-}
-```
 
 ## scripts
 
@@ -368,35 +354,31 @@ handle it.
 
 Example:
 
-```json
-{
-    "scripts": {
-        "post-install-cmd": [
-            "Acme\\ScriptHandler::doSomething"
-        ]
+    {
+        "scripts": {
+            "post-install-cmd": [
+                "Acme\\ScriptHandler::doSomething"
+            ]
+        }
     }
-}
-```
 
 The event handler receives a `Composer\Script\Event` object as an argument,
 which gives you access to the `Composer\Composer` instance through the
 `getComposer` method.
 
-```php
-namespace Acme;
+    namespace Acme;
 
-use Composer\Script\Event;
+    use Composer\Script\Event;
 
-class ScriptHandler
-{
-    static public function doSomething(Event $event)
+    class ScriptHandler
     {
-        $composer = $event->getComposer();
+        static public function doSomething(Event $event)
+        {
+            $composer = $event->getComposer();
 
-        // custom logic
+            // custom logic
+        }
     }
-}
-```
 
 ## extra
 
@@ -405,9 +387,7 @@ Arbitrary extra data for consumption by `scripts`.
 This can be virtually anything. To access it from within a script event
 handler, you can do:
 
-```php
-$extra = $event->getComposer()->getPackage()->getExtra();
-```
+    $extra = $event->getComposer()->getPackage()->getExtra();
 
 Optional.
 

doc/05-repositories.md

@@ -52,18 +52,16 @@ The main repository type is the `composer` repository. It uses a single
 `packages.json` file that contains all of the package metadata. The JSON
 format is as follows:
 
-```json
-{
-    "vendor/packageName": {
-        "name": "vendor/packageName",
-        "description": "Package description",
-        "versions": {
-            "master-dev": { @composer.json },
-            "1.0.0": { @composer.json }
+    {
+        "vendor/packageName": {
+            "name": "vendor/packageName",
+            "description": "Package description",
+            "versions": {
+                "master-dev": { @composer.json },
+                "1.0.0": { @composer.json }
+            }
         }
     }
-}
-```
 
 The `@composer.json` marker would be the contents of the `composer.json` from
 that package version including as a minimum:
@@ -74,16 +72,14 @@ that package version including as a minimum:
 
 Here is a minimal package definition:
 
-```json
-{
-    "name": "smarty/smarty",
-    "version": "3.1.7",
-    "dist": {
-        "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
-        "type": "zip"
+    {
+        "name": "smarty/smarty",
+        "version": "3.1.7",
+        "dist": {
+            "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
+            "type": "zip"
+        }
     }
-}
-```
 
 It may include any of the other fields specified in the [schema].
 
@@ -111,19 +107,17 @@ point to your custom branch.
 
 Example assuming you patched monolog to fix a bug in the `bugfix` branch:
 
-```json
-{
-    "repositories": [
-        {
-            "type": "vcs",
-            "url": "http://github.com/igorw/monolog"
+    {
+        "repositories": [
+            {
+                "type": "vcs",
+                "url": "http://github.com/igorw/monolog"
+            }
+        ],
+        "require": {
+            "monolog/monolog": "dev-bugfix"
         }
-    ],
-    "require": {
-        "monolog/monolog": "dev-bugfix"
     }
-}
-```
 
 When you run `php composer.phar update`, you should get your modified version
 of `monolog/monolog` instead of the one from packagist.
@@ -154,19 +148,17 @@ avoid conflicts.
 
 Example using `pear2.php.net`:
 
-```json
-{
-    "repositories": [
-        {
-            "type": "pear",
-            "url": "http://pear2.php.net"
+    {
+        "repositories": [
+            {
+                "type": "pear",
+                "url": "http://pear2.php.net"
+            }
+        ],
+        "require": {
+            "pear-pear2/PEAR2_HTTP_Request": "*"
         }
-    ],
-    "require": {
-        "pear-pear2/PEAR2_HTTP_Request": "*"
     }
-}
-```
 
 In this case the short name of the channel is `pear2`, so the
 `PEAR2_HTTP_Request` package name becomes `pear-pear2/PEAR2_HTTP_Request`.
@@ -187,31 +179,29 @@ minimum required fields are `name`, `version`, and either of `dist` or
 
 Here is an example for the smarty template engine:
 
-```json
-{
-    "repositories": [
-        {
-            "type": "package",
-            "package": {
-                "name": "smarty/smarty",
-                "version": "3.1.7",
-                "dist": {
-                    "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
-                    "type": "zip"
-                },
-                "source": {
-                    "url": "http://smarty-php.googlecode.com/svn/",
-                    "type": "svn",
-                    "reference": "tags/Smarty_3_1_7/distribution/"
+    {
+        "repositories": [
+            {
+                "type": "package",
+                "package": {
+                    "name": "smarty/smarty",
+                    "version": "3.1.7",
+                    "dist": {
+                        "url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
+                        "type": "zip"
+                    },
+                    "source": {
+                        "url": "http://smarty-php.googlecode.com/svn/",
+                        "type": "svn",
+                        "reference": "tags/Smarty_3_1_7/distribution/"
+                    }
                 }
             }
+        ],
+        "require": {
+            "smarty/smarty": "3.1.*"
         }
-    ],
-    "require": {
-        "smarty/smarty": "3.1.*"
     }
-}
-```
 
 Typically you would leave the source part off, as you don't really need it.
 

doc/articles/scripts.md

@@ -34,33 +34,29 @@ functionality.
 
 Script definition example:
 
-```json
-{
-    "scripts": {
-        "post-update-cmd": "MyVendor\\MyClass::postUpdate",
-        "post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
+    {
+        "scripts": {
+            "post-update-cmd": "MyVendor\\MyClass::postUpdate",
+            "post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
+        }
     }
-}
-```
 
 Script listener example:
 
-```php
-<?php
-
-namespace MyVendor;
+    <?php
 
-class MyClass
-{
-    public static function postUpdate($event)
-    {
-        // do stuff
-    }
+    namespace MyVendor;
 
-    public static function postPackageInstall($event)
+    class MyClass
     {
-        $installedPackage = $event->getOperation()->getPackage();
-        // do stuff
+        public static function postUpdate($event)
+        {
+            // do stuff
+        }
+
+        public static function postPackageInstall($event)
+        {
+            $installedPackage = $event->getOperation()->getPackage();
+            // do stuff
+        }
     }
-}
-```

doc/articles/vendor-bins.md

@@ -16,11 +16,9 @@ It is defined by adding the `bin` key to a project's `composer.json`.
 It is specified as an array of files so multiple bins can be added
 for any given project.
 
-```json
-{
-    "bin": ["bin/my-script", "bin/my-other-script"]
-}
-```
+    {
+        "bin": ["bin/my-script", "bin/my-other-script"]
+    }
 
 
 ## What does defining a bin in composer.json do?
@@ -44,26 +42,22 @@ symlink is created from each dependency's bins to `vendor/bin`.
 
 Say package `my-vendor/project-a` has bins setup like this:
 
-```json
-{
-    "name": "my-vendor/project-a",
-    "bin": ["bin/project-a-bin"]
-}
-```
+    {
+        "name": "my-vendor/project-a",
+        "bin": ["bin/project-a-bin"]
+    }
 
 Running `composer install` for this `composer.json` will not do
 anything with `bin/project-a-bin`.
 
 Say project `my-vendor/project-b` has requirements setup like this:
 
-```json
-{
-    "name": "my-vendor/project-b",
-    "requires": {
-        "my-vendor/project-a": "*"
+    {
+        "name": "my-vendor/project-b",
+        "requires": {
+            "my-vendor/project-a": "*"
+        }
     }
-}
-```
 
 Running `composer install` for this `composer.json` will look at
 all of project-b's dependencies and install them to `vendor/bin`.
@@ -97,13 +91,11 @@ Yes, there are two ways that an alternate vendor bin location can be specified.
 
 An example of the former looks like this:
 
-```json
-{
-    "config": {
-        "bin-dir": "scripts"
+    {
+        "config": {
+            "bin-dir": "scripts"
+        }
     }
-}
-```
 
 Running `composer install` for this `composer.json` will result in
 all of the vendor bins being installed in `scripts/` instead of