docs: "i.e." replaced with "e.g." everywhere in the project

docs/users_guide/framework_basics/basic_concepts.md

@@ -344,7 +344,7 @@ satisfied by all types being or deriving from and instantiation of a `quantity`
     All of `42 * m`, `42 * si::metre`, `42 * isq::height[m]`, and `isq::height(42 * m)` create a quantity
     and thus satisfy a `Quantity` concept.
 
-    A quantity type can also be specified explicitly (i.e. `quantity<si::metre, int>`,
+    A quantity type can also be specified explicitly (e.g. `quantity<si::metre, int>`,
     `quantity<isq::height[m]>`).
 
 ### `QuantityOf<T, V>` { #QuantityOf }

docs/users_guide/framework_basics/generic_interfaces.md

@@ -72,7 +72,7 @@ some issues start to be clearly visible:
     quantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));
     ```
 
-    but the above will obviously provide an incorrect behavior (i.e. division by `0` in the evaluation
+    but the above will obviously provide an incorrect behavior (e.g. division by `0` in the evaluation
     of `s3`).
 
 

docs/users_guide/framework_basics/interface_introduction.md

@@ -40,7 +40,7 @@ to improve the user experience while debugging the program or analyzing the comp
 ## Entities composability
 
 Many physical units libraries (in C++ or any other programming language) assign strong types
-to library entities (i.e. derived units). While `metre_per_second` as a type may not look too
+to library entities (e.g. derived units). While `metre_per_second` as a type may not look too
 scary, consider, for example, units of angular momentum. If we followed this path, its
 [coherent unit](../../appendix/glossary.md#coherent-derived-unit) would look like
 `kilogram_metre_sq_per_second`. Now, consider how many scaled versions of this unit would you
@@ -74,7 +74,7 @@ auto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];
 ```
 
 It is a much better solution. It is terse and easy to understand. Please also notice how
-easy it is to obtain any scaled version of such a unit (i.e. `mg * square(mm) / min`)
+easy it is to obtain any scaled version of such a unit (e.g. `mg * square(mm) / min`)
 without having to introduce hundreds of types to predefine them.
 
 
@@ -207,8 +207,8 @@ the resulting expression template.
     static_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);
     ```
 
-    This is probably the most important of all steps, as it allows comparing types and enables the rest of
-    simplification rules.
+    This is probably the most important of all the steps, as it allows comparing types and enables
+    the rest of simplification rules.
 
 2. **Aggregation**
 

docs/users_guide/framework_basics/quantity_arithmetics.md

@@ -9,7 +9,7 @@ properly constrained set of arithmetic operations on one or two operands.
 
     Every single arithmetic operator is exposed by the `quantity` class template only if
     the underlying representation type provides it as well and its implementation has proper
-    semantics (i.e. returns a reasonable type).
+    semantics (e.g. returns a reasonable type).
 
 For example, in the following code, `-a` will compile only if `MyInt` exposes such an operation
 as well:

docs/users_guide/framework_basics/simple_and_typed_quantities.md

@@ -24,7 +24,7 @@ class quantity;
 
 The concept `Reference` is satisfied by either:
 
-- a unit with an associated quantity type (i.e. `si::metre`)
+- a unit with an associated quantity type (e.g. `si::metre`)
 - a reference type explicitly specifying the quantity type and its unit.
 
 !!! important
@@ -397,7 +397,7 @@ related to quantities, this should be the first function to look for.
 
 In case you wonder which mode you should choose for your project, we have good news for you.
 Simple and typed quantity modes can be freely mixed with each other. When you use different
-quantities of the same kind (i.e. radius, wavelength, altitude, ...), you should probably
+quantities of the same kind (e.g. radius, wavelength, altitude, ...), you should probably
 reach for typed quantities to bring additional safety for those cases. Otherwise, just use
 simple mode for the remaining quantities. The **mp-units** library will do its best to protect
 your project based on the information provided.

docs/users_guide/framework_basics/systems_of_quantities.md

@@ -56,8 +56,8 @@ physical properties.
 
     More than one quantity may be defined for the same dimension:
 
-    - quantities of _different kinds_ (i.e. frequency, modulation rate, activity, ...)
-    - quantities of _the same kind_ (i.e. length, width, altitude, distance, radius, wavelength, position vector, ...)
+    - quantities of _different kinds_ (e.g. frequency, modulation rate, activity, ...)
+    - quantities of _the same kind_ (e.g. length, width, altitude, distance, radius, wavelength, position vector, ...)
 
 It turns out that the above issues can't be solved correctly without proper modeling of
 a [system of quantities](../../appendix/glossary.md#system-of-quantities).

docs/users_guide/framework_basics/systems_of_units.md

@@ -7,7 +7,7 @@ quantities and provide automated conversion factors between various compatible u
 
 Probably all the libraries in the wild model the [SI](../../appendix/glossary.md#si)
 and many of them provide support for additional units belonging to various other systems
-(i.e. imperial).
+(e.g. imperial).
 
 
 ## Systems of Units are based on Systems of Quantities

docs/users_guide/framework_basics/text_output.md

@@ -36,7 +36,7 @@ inline constexpr bool space_before_unit_symbol<non_si::degree> = false;
 !!! note
 
     The above works only for [the default formatting](#default-formatting). In case we provide our own
-    format specification (i.e. `std::format("{:%Q %q}", q)`), the library will always obey this
+    format specification (e.g. `std::format("{:%Q %q}", q)`), the library will always obey this
     specification for all the units (no matter of what is the actual value of the
     `space_before_unit_symbol` customization point) and the separating space will always be present
     in this case.
@@ -130,17 +130,17 @@ In the above grammar:
   chapter of the C++ standard specification,
 - `units-text-encoding` tokens specify the unit text encoding:
     - `U` (default) uses the **Unicode** symbols defined by the [SI](../../appendix/glossary.md#si)
-      specification (i.e. `m³`, `µs`)
-    - `A` token forces non-standard **ASCII**-only output (i.e. `m^3`, `us`)
+      specification (e.g. `m³`, `µs`)
+    - `A` token forces non-standard **ASCII**-only output (e.g. `m^3`, `us`)
 - `units-unit-symbol-solidus` tokens specify how the division of units should look like:
     - `o` (default) outputs `/` only when there is only **one** unit in the denominator, otherwise negative
-      exponents are printed (i.e. `m/s`, `kg m⁻¹ s⁻¹`)
-    - `a` **always** uses solidus (i.e. `m/s`, `kg/(m s)`)
-    - `n` **never** prints solidus, which means that negative exponents are always used (i.e. `m s⁻¹`,
+      exponents are printed (e.g. `m/s`, `kg m⁻¹ s⁻¹`)
+    - `a` **always** uses solidus (e.g. `m/s`, `kg/(m s)`)
+    - `n` **never** prints solidus, which means that negative exponents are always used (e.g. `m s⁻¹`,
       `kg m⁻¹ s⁻¹`)
 - `units-unit-symbol-separator` tokens specify how multiplied unit symbols should be separated:
-    - `s` (default) uses **space** as a separator (i.e. `kg m²/s²`)
-    - `d` uses half-high **dot** (`⋅`) as a separator (i.e. `kg⋅m²/s²`)
+    - `s` (default) uses **space** as a separator (e.g. `kg m²/s²`)
+    - `d` uses half-high **dot** (`⋅`) as a separator (e.g. `kg⋅m²/s²`)
 
 
 ### Default formatting
@@ -266,7 +266,7 @@ std::println("{:%.3GQ %q}", 1.2345678e8 * m);    // 1.23E+08 m
 ### Unit symbol formatting
 
 Unit symbols of some quantities are specified to use Unicode signs by the
-[SI](../../appendix/glossary.md#si) (i.e. `Ω` symbol for the resistance quantity). The **mp-units**
+[SI](../../appendix/glossary.md#si) (e.g. `Ω` symbol for the resistance quantity). The **mp-units**
 library follows this by default. From the engineering point of view, sometimes Unicode text might
 not be the best solution as terminals of many (especially embedded) devices are ASCII-only.
 In such a case, the unit symbol can be forced to be printed using ASCII-only characters thanks to

docs/users_guide/framework_basics/the_affine_space.md

@@ -2,8 +2,8 @@
 
 The affine space has two types of entities:
 
-- **_point_** - a position specified with coordinate values (i.e. location, address, etc.)
-- **_vector_** - the difference between two points (i.e. shift, offset, displacement, duration, etc.)
+- **_point_** - a position specified with coordinate values (e.g. location, address, etc.)
+- **_vector_** - the difference between two points (e.g. shift, offset, displacement, duration, etc.)
 
 
 !!! note
@@ -236,7 +236,7 @@ Taxi distance:   31.2544 km
 !!! note
 
     It is not allowed to subtract two point origins defined in terms of `absolute_point_origin`
-    (i.e. `mean_sea_level - mean_sea_level`) as those do not contain information about the unit
+    (e.g. `mean_sea_level - mean_sea_level`) as those do not contain information about the unit
     so we are not able to determine a resulting `quantity` type.