   do not recommend to run the formatter blindly in an existing codebase.
   Instead you should format and sanity check each formatted file.
 
-  Let's see some examples. The code below:
-
-      "this is a very long string ... #{inspect(some_value)}"
-
-  may be formatted as:
-
-      "this is a very long string ... #{
-        inspect(some_value)
-      }"
-
-  This happens because the only place the formatter can introduce a
-  new line without changing the code semantics is in the interpolation.
-  In those scenarios, we recommend developers to directly adjust the
-  code. Here we can use the binary concatenation operator `<>/2`:
-
-      "this is a very long string " <>
-        "... #{inspect(some_value)}"
-
-  The string concatenation makes the code fit on a single line and also
-  gives more options to the formatter.
-
-  A similar example is when the formatter breaks a function definition
-  over multiple clauses:
+  For example, the formatter may break a long function definition over
+  multiple clauses:
 
       def my_function(
         %User{name: name, age: age, ...},

    * `:force_do_end_blocks` (since v1.9.0) - when `true`, converts all
      inline usages of `do: ...`,  `else: ...` and friends into `do/end`
      blocks. Defaults to `false`. Note that this option is convergent:
      once you set it to `true`, all keywords will be converted. If you
      set it to `false` later on, `do/end` blocks won't be converted
      back to keywords.

  ## Design principles



    * `:line_length` - the line length to aim for when formatting
      the document. Defaults to 98. Note this value is used as
      guideline but there are situations where it is not enforced.
      See the "Line length" section below for more information

    * `:locals_without_parens` - a keyword list of name and arity
      pairs that should be kept without parens whenever possible.
