Update the comparison docs to account for eza's new theme support (#112)

Co-authored-by: Dhruv Bhanushali <[email protected]>

docs/src/content/docs/about/comparison.mdx

@@ -32,20 +32,19 @@ alternatives, [eza](https://eza.rocks) and its predecessor
   [importance](/features/importance/), making it suitable for modern dev
   workflows involving tooling configs.
 
-- eza uses arcane environment variables for customisation. <Pls /> uses
-  [cascading YAML files](/reference/conf/) to enable per-project configuration
-  that's also more readable, maintainable and ergonomic. You can also check
-  these config files into your VCS and share them with your team.
+- eza supports theming using a global YAML file like <Pls />. But <Pls /> goes
+  further with [cascading YAML files](/reference/conf/) to enable per-project
+  configuration that's also more readable, maintainable and ergonomic. You can
+  also check these config files into your VCS and share them with your team.
 
 - eza uses globs which limits the match to simple queries. <Pls /> uses
   [specs](/guides/specs/) which match files using the full power of regex and
   then provide both styling and [icons](/features/icons/) for their matches.
   These specs can also be cascaded.
 
-- eza output is very colorful, but limited to customisation using ANSI escape
-  codes. <Pls /> employs sparse color and formatting, to add meaning or context,
-  and these [styles](/guides/markup/) can be customised using English names or
-  even RGB notation.
+- eza's output is very colorful by default whereas <Pls /> employs sparse color
+  and formatting, to add meaning or context. <Pls /> [markup](/guides/markup/)
+  syntax is more compact than eza's separate fields for colors and styles.
 
 - <Pls /> has more [metadata fields](/features/detail_view/) compared to eza. It
   also allows the user to view some metadata fields in multiple ways (including