feat: add #eg function

Author: drupol

src/thesis/2-reproducibility.typ

@@ -540,8 +540,8 @@ of software without legal or technical barriers. This flexibility is vital for
 verifying and replicating studies, as researchers can adapt the software for
 their specific needs without restrictions, though some licences may impose
 certain conditions. Additionally, open-source development tools provide
-excellent record-keeping capabilities, like version control systems (e.g.,
-`git`, Mercurial, Pijul), enabling researchers to track changes and understand
+excellent record-keeping capabilities, like version control systems #eg[
+`git`, Mercurial, Pijul], enabling researchers to track changes and understand
 the context of each update. This aspect is essential for reproducing and
 validating research findings.
 
@@ -620,7 +620,7 @@ execution, a data analysis, a data transformation.
 - When evaluating a function, method, or procedure in any programming language,
   the input consists of the function itself along with its parameters. The
   output is the result of the function applied to these parameters, including
-  any potential side effects (e.g., changes in the program's state).
+  any potential side effects #eg[changes in the program's state].
 
 #definition(term: "Computation", name: "def-computation")[
   A computation $c$ is a set of one or more functions $f:I times E → R$.
@@ -689,9 +689,9 @@ operations.
 In #gls("CS") (@functions-in-cs), a function necessitates an environment in
 which it will be evaluated, effectively making, to some extent, this environment
 an extra input parameter per se. This computational environment, which
-encompasses the hardware (e.g., filesystem, memory, #gls("CPU", long: false)),
-software (e.g., #gls("OS", long: false)) and date (e.g., the current date and
-time), may influence the function's behaviour and output. Consequently,
+encompasses the hardware #eg[(filesystem, memory, #gls("CPU", long: false)],
+software #eg[#gls("OS", long: false)] and date #eg[the current date and
+time], may influence the function's behaviour and output. Consequently,
 functions in #gls("CS") are inherently designed to interact with and adapt to
 their environment, thereby making them dynamic and versatile but also
 potentially non-deterministic.
@@ -743,9 +743,9 @@ reproducibility of the computations discussed.
 In the context of software compilation, an output is correct when it faithfully
 reflects the state of its transitive inputs. Basically, the output represents
 all direct and indirect dependencies used in the build process.
-"Transitive inputs" refer to not only the direct inputs (e.g., source code) but
-also to the inputs of those inputs (e.g., libraries, frameworks, compilers, data
-resources).
+"Transitive inputs" refer to not only the direct inputs #eg[source code] but
+also to the inputs of those inputs #eg[libraries, frameworks, compilers, data
+resources].
 
 From the point of view of the software build process as shown in
 @inputs-outputs-part1, the inputs are all the source code files, configuration
@@ -1016,8 +1016,8 @@ unique" is used because, in theory, it is possible for two different inputs to
 produce the same hash, an occurrence known as a #emph[collision]. The ability to
 find collisions undermines the security of the algorithm. There are different
 types of algorithms to calculate a checksum
-(e.g., #gls("MD5", long: false), #gls("SHA1", long: false),
-#gls("SHA2", long: false)). Older algorithms like #gls("MD5", long: false) have
+#eg[#gls("MD5", long: false), #gls("SHA1", long: false),
+#gls("SHA2", long: false)]. Older algorithms like #gls("MD5", long: false) have
 known vulnerabilities that allow collision attacks while more modern algorithms
 like SHA-256 (#gls("SHA2", long: false)) are currently considered to be pretty
 much impossible to crack.
@@ -1371,7 +1371,7 @@ source code. This variance highlights a significant reproducibility challenge,
 as achieving bitwise identical results across architectures is *not feasible* as
 of today.
 
-Compilers (e.g., GCC, Rustc, #LaTeX, Typst) also play a role in software
+Compilers #eg[GCC, Rustc, #LaTeX, Typst] also play a role in software
 development, transforming high-level code into machine-level instructions.
 However, not all compilers operate deterministically. In this context,
 non-determinism refers to the phenomenon where compilers produce different

src/thesis/3-tools.typ

@@ -477,7 +477,7 @@ been pinned to a specific commit at lines 1 and 7.
   consistently, regardless of any upstream updates. While using a digest to pin
   the base image ensures immutability, the `apk` package manager does not
   support a similar mechanism, only tags are supported. It's important to be
-  aware of the limitations of the tools (e.g., the `apk` package manager) used
+  aware of the limitations of the tools #eg[the `apk` package manager] used
   in the base image, as even with precautions, variability in the build process
   may still be introduced.
 ]

src/thesis/4-conclusion.typ

@@ -190,8 +190,8 @@ the intermediary VM layer. On Linux based architectures, the performance are not
 as good as running the software natively without containerisation, but it
 remains acceptable for most use cases. Although initiatives like DevContainer
 #cite(<devcontainer>, form: "normal") aim to offer a more integrated experience
-with #glspl("IDE", long: false) (e.g., Visual Studio Code
-#cite(<vscode>, form: "normal")), working within a container introduces an
+with #glspl("IDE", long: false) #eg[Visual Studio Code
+#cite(<vscode>, form: "normal")], working within a container introduces an
 additional layer of complexity. This can be particularly challenging to manage
 when dealing with aspects such as networking, storage, and security.
 
@@ -306,7 +306,7 @@ consistency and reliability in package management.
   choice. With two decades of maturity and robustness, the Nix ecosystem is, in
   my view, currently the best concept for implementing reproducibility in
   #gls("SE"). I am convinced that Nix, or a similar technology that embraces the
-  same principles (e.g., @guixwebsite, @lix, @aux), has the potential to
+  same principles #eg[@guixwebsite, @lix, @aux], has the potential to
   revolutionise the way software is built, used, audited, deployed and shared.
 ]
 
@@ -347,7 +347,7 @@ evaluation.
 Achieving software build reproducibility across different operating systems and
 architectures is not feasible for certain types of build outputs, typically
 binaries (@ch2-r13y-utopia). Binary build outputs depend on the #gls("CPU")
-architecture (e.g., `x86`, `ARM`) because converting source code into machine
+architecture #eg[`x86`, `ARM`] because converting source code into machine
 code uses a set of #gls("CPU") instructions directly inherited from the
 #gls("CPU") architecture. Therefore, obtaining binaries that are identical
 across every architecture is unlikely to occur. This inherent dependency means

src/thesis/imports/workarounds.typ

@@ -54,4 +54,10 @@
 ));h(-8.0pt)
 }
 
+#let eg = content => {
+  [
+    (e.g., #content)
+  ]
+}
+
 #show "LaTeX": LaTeX