fix: docs indentation (#2448)

* fix: docs indentation

* docs: last fixes indentation

Co-authored-by: PrettyWood <em.jolibois@gmail.com>

docs/usage/settings.md

@@ -22,19 +22,19 @@ _(This script is complete, it should run "as is")_
 The following rules are used to determine which environment variable(s) are read for a given field:
 
 * By default, the environment variable name is built by concatenating the prefix and field name.
-    * For example, to override `special_function` above, you could use:
+  * For example, to override `special_function` above, you could use:
 
-            export my_prefix_special_function='foo.bar'
+          export my_prefix_special_function='foo.bar'
 
-    * Note 1: The default prefix is an empty string.
-    * Note 2: Field aliases are ignored when building the environment variable name.
+  * Note 1: The default prefix is an empty string.
+  * Note 2: Field aliases are ignored when building the environment variable name.
 
 * Custom environment variable names can be set in two ways:
-    * `Config.fields['field_name']['env']` (see `auth_key` and `redis_dsn` above)
-    * `Field(..., env=...)` (see `api_key` above)
+  * `Config.fields['field_name']['env']` (see `auth_key` and `redis_dsn` above)
+  * `Field(..., env=...)` (see `api_key` above)
 * When specifying custom environment variable names, either a string or a list of strings may be provided.
-    * When specifying a list of strings, order matters: the first detected value is used.
-    * For example, for `redis_dsn` above, `service_redis_dsn` would take precedence over `redis_url`.
+  * When specifying a list of strings, order matters: the first detected value is used.
+  * For example, for `redis_dsn` above, `service_redis_dsn` would take precedence over `redis_url`.
 
 !!! warning
     Since **v1.0** *pydantic* does not consider field aliases when finding environment variables to populate settings

docs/usage/types.md

@@ -279,37 +279,37 @@ types:
 
 * `datetime` fields can be:
 
-    * `datetime`, existing `datetime` object
-    * `int` or `float`, assumed as Unix time, i.e. seconds (if >= `-2e10` or <= `2e10`) or milliseconds (if < `-2e10`or > `2e10`) since 1 January 1970
-    * `str`, following formats work:
+  * `datetime`, existing `datetime` object
+  * `int` or `float`, assumed as Unix time, i.e. seconds (if >= `-2e10` or <= `2e10`) or milliseconds (if < `-2e10`or > `2e10`) since 1 January 1970
+  * `str`, following formats work:
 
-        * `YYYY-MM-DD[T]HH:MM[:SS[.ffffff]][Z or [±]HH[:]MM]]]`
-        * `int` or `float` as a string (assumed as Unix time)
+    * `YYYY-MM-DD[T]HH:MM[:SS[.ffffff]][Z or [±]HH[:]MM]]]`
+    * `int` or `float` as a string (assumed as Unix time)
 
 * `date` fields can be:
 
-    * `date`, existing `date` object
-    * `int` or `float`, see `datetime`
-    * `str`, following formats work:
+  * `date`, existing `date` object
+  * `int` or `float`, see `datetime`
+  * `str`, following formats work:
 
-        * `YYYY-MM-DD`
-        * `int` or `float`, see `datetime`
+    * `YYYY-MM-DD`
+    * `int` or `float`, see `datetime`
 
 * `time` fields can be:
 
-    * `time`, existing `time` object
-    * `str`, following formats work:
+  * `time`, existing `time` object
+  * `str`, following formats work:
 
-        * `HH:MM[:SS[.ffffff]][Z or [±]HH[:]MM]]]`
+    * `HH:MM[:SS[.ffffff]][Z or [±]HH[:]MM]]]`
 
 * `timedelta` fields can be:
 
-    * `timedelta`, existing `timedelta` object
-    * `int` or `float`, assumed as seconds
-    * `str`, following formats work:
+  * `timedelta`, existing `timedelta` object
+  * `int` or `float`, assumed as seconds
+  * `str`, following formats work:
 
-        * `[-][DD ][HH:MM]SS[.ffffff]`
-        * `[±]P[DD]DT[HH]H[MM]M[SS]S` (ISO 8601 format for timedelta)
+    * `[-][DD ][HH:MM]SS[.ffffff]`
+    * `[±]P[DD]DT[HH]H[MM]M[SS]S` (ISO 8601 format for timedelta)
 
 ```py
 {!.tmp_examples/types_dt.py!}

docs/usage/validators.md

@@ -11,10 +11,10 @@ A few things to note on validators:
   of `UserModel`.
 * the second argument is always the field value to validate; it can be named as you please
 * you can also add any subset of the following arguments to the signature (the names **must** match):
-    * `values`: a dict containing the name-to-value mapping of any previously-validated fields
-    * `config`: the model config
-    * `field`: the field being validated. Type of object is `pydantic.fields.ModelField`.
-    * `**kwargs`: if provided, this will include the arguments above not explicitly listed in the signature
+  * `values`: a dict containing the name-to-value mapping of any previously-validated fields
+  * `config`: the model config
+  * `field`: the field being validated. Type of object is `pydantic.fields.ModelField`.
+  * `**kwargs`: if provided, this will include the arguments above not explicitly listed in the signature
 * validators should either return the parsed value or raise a `ValueError`, `TypeError`, or `AssertionError`
   (``assert`` statements may be used).
 
@@ -25,13 +25,13 @@ A few things to note on validators:
 
 * where validators rely on other values, you should be aware that:
 
-    - Validation is done in the order fields are defined.
-      E.g. in the example above, `password2` has access to `password1` (and `name`),
-      but `password1` does not have access to `password2`. See [Field Ordering](models.md#field-ordering)
-      for more information on how fields are ordered
+  * Validation is done in the order fields are defined.
+    E.g. in the example above, `password2` has access to `password1` (and `name`),
+    but `password1` does not have access to `password2`. See [Field Ordering](models.md#field-ordering)
+    for more information on how fields are ordered
 
-    - If validation fails on another field (or that field is missing) it will not be included in `values`, hence
-      `if 'password1' in values and ...` in this example.
+  * If validation fails on another field (or that field is missing) it will not be included in `values`, hence
+    `if 'password1' in values and ...` in this example.
 
 ## Pre and per-item validators