///
/// # Handling errors and matching on `ErrorKind`
///
-/// In application code, use `match` for the `ErrorKind` values you are
+/// In application code, use `match` for the `ErrorKind` values you are
/// expecting; use `_` to match "all other errors".
///
-/// In comprehensive and thorough tests that want to verify that a test doesn't
-/// return any known incorrect error kind, you may want to cut-and-paste the
-/// current full list of errors from here into your test code, and then match
-/// `_` as the correct case. This seems counterintuitive, but it will make your
+/// In comprehensive and thorough tests that want to verify that a test doesn't
+/// return any known incorrect error kind, you may want to cut-and-paste the
+/// current full list of errors from here into your test code, and then match
+/// `_` as the correct case. This seems counterintuitive, but it will make your
/// tests more robust. In particular, if you want to verify that your code does
/// produce an unrecognized error kind, the robust solution is to check for all
/// the recognized error kinds and fail in those cases.