Fixed problems with format

src/main/scala/doobie/ConnectingToDatabaseSection.scala

@@ -45,7 +45,7 @@ import org.scalatest._
  * import cats.implicits._
  * }}}
  *
- * n the doobie high level API the most common types we will deal with have the form `ConnectionIO[A]`,
+ * In the doobie high level API the most common types we will deal with have the form `ConnectionIO[A]`,
  * specifying computations that take place in a context where a `java.sql.Connection` is available,
  * ultimately producing a value of type `A`.
  *
@@ -59,12 +59,12 @@ import org.scalatest._
  * This is a perfectly respectable doobie program, but we can’t run it as-is; we need a `Connection`
  * first. There are several ways to do this, but here let’s use a `Transactor`.
  *
- * > Note: DriverManagerTransactors have the advantage of no connection pooling and configuration, so
- * > are perfect for testing. The main disadvantage is that it is slower than pooling connection managers,
- * > no provides upper bound for concurrent connections and executes blocking operations in an unbounded
- * > pool of threads. The `doobie-hikari` add-on provides a `Transactor` implementation backed by a HikariCP
- * > connection pool. The connection pool is a lifetime-managed object that must be shut down cleanly, so
- * > it is managed as a Resource.
+ * '''Note''': DriverManagerTransactors have the advantage of no connection pooling and configuration, so
+ * are perfect for testing. The main disadvantage is that it is slower than pooling connection managers,
+ * no provides upper bound for concurrent connections and executes blocking operations in an unbounded
+ * pool of threads. The `doobie-hikari` add-on provides a `Transactor` implementation backed by a HikariCP
+ * connection pool. The connection pool is a lifetime-managed object that must be shut down cleanly, so
+ * it is managed as a Resource.
  *
  * {{{
  * import doobie.hikari._

src/main/scala/doobie/ErrorHandlingSection.scala

@@ -25,17 +25,18 @@ import org.scalatest.{FlatSpec, Matchers}
  *
  * There are three main types of exceptions that are likely to arise:
  *
- * 1. Various types of `IOException` can happen with any kind of I/O, and these exceptions tend to be unrecoverable.
+ * '''1.''' Various types of `IOException` can happen with any kind of I/O, and these exceptions tend to be
+ * unrecoverable.
  *
- * 2. Database exceptions, typically as a generic `SQLException` with a vendor-specific `SQLState` identifying the
+ * '''2.''' Database exceptions, typically as a generic `SQLException` with a vendor-specific `SQLState` identifying the
  * specific error, are raised for common situations such as key violations. Some vendors (PostgreSQL for instance)
  * publish a table of error codes, and in these cases doobie can provide a matching set of exception-handling
  * combinators. However in most cases the error codes must be passed down as folklore or discovered by
  * experimentation. There exist the XOPEN and SQL:2003 standards, but it seems that no vendor adheres closely to
  * these specifications. Some of these errors are recoverable and others aren’t.
  *
- * 3. doobie will raise an `InvariantViolation` in response to invalid type mappings, unknown JDBC constants returned
- * by drivers, observed `NULL` values, and other violations of invariants that doobie assumes. These exceptions
+ * '''3.''' doobie will raise an `InvariantViolation` in response to invalid type mappings, unknown JDBC constants
+ * returned by drivers, observed `NULL` values, and other violations of invariants that doobie assumes. These exceptions
  * indicate programmer error or driver non-compliance and are generally unrecoverable.
  *
  * ==MonadError and Derived Combinators==