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.*"
         }
-}
+    }
-```
 
 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.*"
         }
-}
+    }
-```
 
 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 = new Monolog\Logger('name');
+    $log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Logger::WARNING));
-$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/"}
         }
-}
+    }
-```
 
 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 = require 'vendor/.composer/autoload.php';
+    $loader->add('Acme\Test', __DIR__);
-$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.*"
         }
-}
+    }
-```
 
 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"
-}
+    }
-```
 
 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"
         }
-}
+    }
-```
 
 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,8 +116,7 @@ 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": {
@@ -133,8 +126,7 @@ We do this by adding a package repository specification to the blog's
         "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,8 +134,7 @@ Each author object can have following properties:
 
 An example:
 
-```json
+    {
-{
         "authors": [
             {
                 "name": "Nils Adermann",
@@ -148,8 +147,7 @@ An example:
                 "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.*"
         }
-}
+    }
-```
 
 Optional.
 
@@ -194,13 +190,11 @@ package root.
 
 Example:
 
-```json
+    {
-{
         "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"
-}
+    }
-```
 
 Optional.
 
@@ -259,8 +251,7 @@ For more information on any of these, see [Repositories].
 
 Example:
 
-```json
+    {
-{
         "repositories": [
             {
                 "type": "composer",
@@ -291,8 +282,7 @@ Example:
                 }
             }
         ]
-}
+    }
-```
 
 > **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
             }
         ]
-}
+    }
-```
 
 ## config
 
@@ -327,13 +315,11 @@ The following options are supported:
 
 Example:
 
-```json
+    {
-{
         "config": {
             "bin-dir": "bin"
         }
-}
+    }
-```
 
 ## scripts
 
@@ -368,35 +354,31 @@ handle it.
 
 Example:
 
-```json
+    {
-{
         "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
+    class ScriptHandler
-{
+    {
         static public function doSomething(Event $event)
         {
             $composer = $event->getComposer();
 
             // 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,8 +52,7 @@ 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",
@@ -62,8 +61,7 @@ format is as follows:
                 "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"
         }
-}
+    }
-```
 
 It may include any of the other fields specified in the [schema].
 
@@ -111,8 +107,7 @@ point to your custom branch.
 
 Example assuming you patched monolog to fix a bug in the `bugfix` branch:
 
-```json
+    {
-{
         "repositories": [
             {
                 "type": "vcs",
@@ -122,8 +117,7 @@ Example assuming you patched monolog to fix a bug in the `bugfix` branch:
         "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,8 +148,7 @@ avoid conflicts.
 
 Example using `pear2.php.net`:
 
-```json
+    {
-{
         "repositories": [
             {
                 "type": "pear",
@@ -165,8 +158,7 @@ Example using `pear2.php.net`:
         "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,8 +179,7 @@ minimum required fields are `name`, `version`, and either of `dist` or
 
 Here is an example for the smarty template engine:
 
-```json
+    {
-{
         "repositories": [
             {
                 "type": "package",
@@ -210,8 +201,7 @@ Here is an example for the smarty template engine:
         "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,24 +34,21 @@ functionality.
 
 Script definition example:
 
-```json
+    {
-{
         "scripts": {
             "post-update-cmd": "MyVendor\\MyClass::postUpdate",
             "post-package-install": ["MyVendor\\MyClass::postPackageInstall"]
         }
-}
+    }
-```
 
 Script listener example:
 
-```php
+    <?php
-<?php
 
-namespace MyVendor;
+    namespace MyVendor;
 
-class MyClass
+    class MyClass
-{
+    {
         public static function postUpdate($event)
         {
             // do stuff
@@ -62,5 +59,4 @@ class MyClass
             $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"]
-}
+    }
-```
 
 
 ## 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"]
-}
+    }
-```
 
 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": "*"
         }
-}
+    }
-```
 
 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"
         }
-}
+    }
-```
 
 Running `composer install` for this `composer.json` will result in
 all of the vendor bins being installed in `scripts/` instead of