 
   ### Custom formatting
 
-  The console backend allows you to customize the format of your log messages
-  with the `:format` option.
-
-  You may set `:format` to either a string or a `{module, function}` tuple if
-  you wish to provide your own format function. Here is an example of how to
-  configure the `:console` backend in a `config/config.exs` file:
+  The console backend allows you to customize the format of your
+  log messages with the `:format` option.
+
+  You may set `:format` to either a string or a `{module, function}`
+  tuple if you wish to provide your own format function. Here is an
+  example of how to configure the `:console` backend in a
+  `config/config.exs` file:
 
       config :logger, :console,
         format: {MyConsoleLogger, :format}
 
-  And here is an example of how you can define `MyConsoleLogger.format/4` from the
-  above configuration:
+  And here is an example of how you can define `MyConsoleLogger.format/4`
+  from the above configuration:
 
       defmodule MyConsoleLogger do
         def format(level, message, timestamp, metadata) do

        end
      end

  It is extremely important that **the formatting function does not fail**, as
  it will bring that particular logger instance down, causing your system to
  temporarily lose messages. If necessary, wrap the function in a `rescue` and
  log a default message instead:

      defmodule MyConsoleLogger do
        def format(level, message, timestamp, metadata) do

  The `{module, function}` will be invoked with four arguments:

    * the log level: an atom
    * the message: this is usually chardata, but in some cases it
      may contain invalid data. Since the formatting function should
      *never* fail, you need to prepare for the message being anything
    * the current timestamp: a term of type `t:Logger.Formatter.time/0`
    * the metadata: a keyword list

  You can read more about formatting in `Logger.Formatter`, especially
  if you want to support custom formatting in a custom backend.

  ### Custom backends

  Any developer can create their own `Logger` backend. Since `Logger`
  is an event manager powered by `:gen_event`, writing a new backend
  is a matter of creating an event handler, as described in the
  [`:gen_event`](http://erlang.org/doc/man/gen_event.html) documentation.

  From now on, we will be using the term "event handler" to refer
  to your custom backend, as we head into implementation details.

  Once the `:logger` application starts, it installs all event handlers
  listed under the `:backends` configuration into the `Logger` event
  manager. The event manager and all added event handlers are automatically
  supervised by `Logger`.

  Note that if a backend fails to start by returning `{:error, :ignore}`
  from its `init/1` callback, then it's not added to the backends but
  nothing fails. If a backend fails to start by returning `{:error, reason}`
  from its `init/1` callback, the `:logger` application will fail to start.

  Once initialized, the handler should be designed to handle the
  following events:

    * `{level, group_leader, {Logger, message, timestamp, metadata}}` where:
      * `level` is one of `:debug`, `:info`, `:warn`, or `:error`, as previously
