 
   ### Application configuration
 
-  The following configuration must be set via config files
-  before the Logger application is started.
+  The following configuration must be set via config files (e.g.,
+  `config/config.exs`) before the `:logger` application is started.
 
     * `:backends` - the backends to be used. Defaults to `[:console]`.
       See the "Backends" section for more information.
 
-    * `:compile_time_purge_level` - purge all calls that have log level
-      lower than the configured value at compilation time. This means the
-      Logger call will be completely removed at compile time, accruing
-      no overhead at runtime. Defaults to `:debug` and only
-      applies to the `Logger.debug/2`, `Logger.info/2`, etc style of calls.
-      Note that in calls are removed from the AST at compilation time, the
-      passed arguments are never evaluated, so any function call that occurs in
-      these arguments is never executed. As a consequence, avoid code that looks
-      like `Logger.debug("Cleanup: #{perform_cleanup()}")` as in the example
-      `perform_cleanup/0` won't be executed if the `:compile_time_purge_level`
-      is `:info` or higher.
+    * `:compile_time_purge_level` - purge *at compilation time* all calls that
+      have log level lower than the value of this option. This means that
+      `Logger` calls with level lower than this option will be completely
+      removed at compile time, accruing no overhead at runtime. Defaults to
+      `:debug` and only applies to the `Logger.debug/2`, `Logger.info/2`,
+      `Logger.warn/2`, and `Logger.error/2` macros (e.g., it doesn't apply to
+      `Logger.log/3`). Note that arguments passed to `Logger` calls that are
+      removed from the AST at compilation time are never evaluated, thus any
+      function call that occurs in these arguments is never executed. As a
+      consequence, avoid code that looks like `Logger.debug("Cleanup:
+      #{perform_cleanup()}")` as in the example `perform_cleanup/0` won't be
+      executed if the `:compile_time_purge_level` is `:info` or higher.
 
     * `:compile_time_application` - sets the `:application` metadata value
       to the configured value at compilation time. This configuration is
       usually only useful for build tools to automatically add the
-      application to the metadata for `Logger.debug/2`, `Logger.info/2`, etc
+      application to the metadata for `Logger.debug/2`, `Logger.info/2`, etc.
       style of calls.
 
   For example, to configure the `:backends` and `compile_time_purge_level`
-  in a `config/config.exs` file:
+  options in a `config/config.exs` file:
 
       config :logger,
         backends: [:console],


  ## Backends

  Logger supports different backends where log messages are written to.

  The available backends by default are:

    * `:console` - logs messages to the console (enabled by default)

  Developers may also implement their own backends, an option that
  is explored with detail below.

  The initial backends are loaded via the `:backends` configuration,
  which must be set before the Logger application is started.

  ### Console backend

  The console backend logs message to the console. It supports the
  following options:

    * `:level` - the level to be logged by this backend.
      Note that messages are first filtered by the general
      `:level` configuration in `:logger`

    * `:format` - the format message used to print logs.
      Defaults to: `"$time $metadata[$level] $levelpad$message\n"`

    * `:metadata` - the metadata to be printed by `$metadata`.
      Defaults to an empty list (no metadata)

    * `:colors` - a keyword list of coloring options.


      threshold, the `error_logger` enters discard mode for the
      remainder of that second. Defaults to 500 messages.

  For example, to configure `Logger` to redirect all `error_logger` messages
  using a `config/config.exs` file:

      config :logger,
        handle_otp_reports: true,
        handle_sasl_reports: true

  Furthermore, `Logger` allows messages sent by Erlang's `error_logger`
  to be translated into an Elixir format via translators. Translators
  can be dynamically added at any time with the `add_translator/1`
  and `remove_translator/1` APIs. Check `Logger.Translator` for more
