Automated deployment: Mon Jun 28 05:35:02 UTC 2021 8ad962214a

en/index.html

@@ -150,12 +150,12 @@
                 <div id="content" class="content">
                     <main>
                         <h1 id="introduction"><a class="header" href="#introduction">Introduction</a></h1>
-<p><code>xplr</code> is a terminal UI based file explorer that aims to increase our terminal
+<p>xplr is a terminal UI based file explorer that aims to increase our terminal
 productivity by being a flexible, interactive orchestrator for the ever growing
 awesome command-line utilities that work with the file-system.</p>
-<p>To achieve its goal, <code>xplr</code> strives to be a fast, minimal and more importantly,
+<p>To achieve its goal, xplr strives to be a fast, minimal and more importantly,
 hackable file explorer.</p>
-<p><code>xplr</code> is not meant to be a replacement for the standard shell commands or the
+<p>xplr is not meant to be a replacement for the standard shell commands or the
 GUI file managers. Rather, it aims to integrate them all and expose an
 intuitive, scriptable, keyboard controlled, real-time visual interface, also
 being an ideal candidate for further integration, enabling the users to achieve
@@ -164,31 +164,31 @@ insane terminal productivity.</p>
 <h3 id="hackable"><a class="header" href="#hackable">Hackable</a></h3>
 <p>xplr is built with configurability in mind. So it allows you to perform a vast
 set of operations and make it behave just the way you want.</p>
-<p>A few things you can do with the [<code>xplr</code>][xplr] configuration</p>
+<p>A few things you can do with the xplr configuration</p>
 <ul>
 <li><a href="layouts.html">Hack the layout</a></li>
 <li><a href="modes.html">Hack the key bindings</a></li>
 <li><a href="awesome-plugins.html">Extend with plugins</a></li>
 </ul>
 <h2 id="fast"><a class="header" href="#fast">Fast</a></h2>
-<p>Although speed is not the primary concern, [<code>xplr</code>][xplr] is already fast
-enough so that you can take it out for a walk into your <code>node_modules</code> or
-<code>/nix/store</code> any time you want. I currently
+<p>Although speed is not the primary concern, xplr is already fast enough so that
+you can take it out for a walk into your <code>node_modules</code> or <code>/nix/store</code> any
+time you want. I currently
 <a href="https://github.com/sayanarijit/xplr/tree/main/benches">measure the most commonly used operations</a>
 and I have seen it improve significantly over time, and it's only the start.</p>
 <p><strong>Tip:</strong> A quick and easy way to optimize UI rendering is reducing the number
 of columns in the table.</p>
-<p><strong>Note:</strong> If you feel [<code>xplr</code>][xplr] is not behaving at its optimal, this is
-probably because I am waiting for someone to complain. I want to avoid
-optimizing things I don't need to, because optimization often requires either
-complexity or feature sacrifice or both.</p>
+<p><strong>Note:</strong> If you feel xplr is not behaving at its optimal, this is probably
+because I am waiting for someone to complain. I want to avoid optimizing things
+I don't need to, because optimization often requires either complexity or
+feature sacrifice or both.</p>
 <h2 id="minimalist"><a class="header" href="#minimalist">Minimalist</a></h2>
-<p>[<code>xplr</code>][xplr] prefers to stay minimal, both in terms of features and binary
-size, but just like speed, minimalism isn't as aggressively pursued as
-configurability. If adding some feature, lines of code, or a dependency allows
-the users to be a little more productive or allows [<code>xplr</code>][xplr] to be a
-little more configurable, it will be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance will also be considered in the
-decision-making.</p>
+<p>xplr prefers to stay minimal, both in terms of features and binary size, but
+just like speed, minimalism isn't as aggressively pursued as configurability.
+If adding some feature, lines of code, or a dependency allows the users to be a
+little more productive or allows xplr to be a little more configurable, it will
+be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance
+will also be considered in the decision-making.</p>
 <h2 id="other-features"><a class="header" href="#other-features">Other features</a></h2>
 <ul>
 <li><a href="https://github.com/sayanarijit/xplr/discussions/183">Embedded LuaJIT</a> for

en/introduction.html

@@ -150,12 +150,12 @@
                 <div id="content" class="content">
                     <main>
                         <h1 id="introduction"><a class="header" href="#introduction">Introduction</a></h1>
-<p><code>xplr</code> is a terminal UI based file explorer that aims to increase our terminal
+<p>xplr is a terminal UI based file explorer that aims to increase our terminal
 productivity by being a flexible, interactive orchestrator for the ever growing
 awesome command-line utilities that work with the file-system.</p>
-<p>To achieve its goal, <code>xplr</code> strives to be a fast, minimal and more importantly,
+<p>To achieve its goal, xplr strives to be a fast, minimal and more importantly,
 hackable file explorer.</p>
-<p><code>xplr</code> is not meant to be a replacement for the standard shell commands or the
+<p>xplr is not meant to be a replacement for the standard shell commands or the
 GUI file managers. Rather, it aims to integrate them all and expose an
 intuitive, scriptable, keyboard controlled, real-time visual interface, also
 being an ideal candidate for further integration, enabling the users to achieve
@@ -164,31 +164,31 @@ insane terminal productivity.</p>
 <h3 id="hackable"><a class="header" href="#hackable">Hackable</a></h3>
 <p>xplr is built with configurability in mind. So it allows you to perform a vast
 set of operations and make it behave just the way you want.</p>
-<p>A few things you can do with the [<code>xplr</code>][xplr] configuration</p>
+<p>A few things you can do with the xplr configuration</p>
 <ul>
 <li><a href="layouts.html">Hack the layout</a></li>
 <li><a href="modes.html">Hack the key bindings</a></li>
 <li><a href="awesome-plugins.html">Extend with plugins</a></li>
 </ul>
 <h2 id="fast"><a class="header" href="#fast">Fast</a></h2>
-<p>Although speed is not the primary concern, [<code>xplr</code>][xplr] is already fast
-enough so that you can take it out for a walk into your <code>node_modules</code> or
-<code>/nix/store</code> any time you want. I currently
+<p>Although speed is not the primary concern, xplr is already fast enough so that
+you can take it out for a walk into your <code>node_modules</code> or <code>/nix/store</code> any
+time you want. I currently
 <a href="https://github.com/sayanarijit/xplr/tree/main/benches">measure the most commonly used operations</a>
 and I have seen it improve significantly over time, and it's only the start.</p>
 <p><strong>Tip:</strong> A quick and easy way to optimize UI rendering is reducing the number
 of columns in the table.</p>
-<p><strong>Note:</strong> If you feel [<code>xplr</code>][xplr] is not behaving at its optimal, this is
-probably because I am waiting for someone to complain. I want to avoid
-optimizing things I don't need to, because optimization often requires either
-complexity or feature sacrifice or both.</p>
+<p><strong>Note:</strong> If you feel xplr is not behaving at its optimal, this is probably
+because I am waiting for someone to complain. I want to avoid optimizing things
+I don't need to, because optimization often requires either complexity or
+feature sacrifice or both.</p>
 <h2 id="minimalist"><a class="header" href="#minimalist">Minimalist</a></h2>
-<p>[<code>xplr</code>][xplr] prefers to stay minimal, both in terms of features and binary
-size, but just like speed, minimalism isn't as aggressively pursued as
-configurability. If adding some feature, lines of code, or a dependency allows
-the users to be a little more productive or allows [<code>xplr</code>][xplr] to be a
-little more configurable, it will be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance will also be considered in the
-decision-making.</p>
+<p>xplr prefers to stay minimal, both in terms of features and binary size, but
+just like speed, minimalism isn't as aggressively pursued as configurability.
+If adding some feature, lines of code, or a dependency allows the users to be a
+little more productive or allows xplr to be a little more configurable, it will
+be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance
+will also be considered in the decision-making.</p>
 <h2 id="other-features"><a class="header" href="#other-features">Other features</a></h2>
 <ul>
 <li><a href="https://github.com/sayanarijit/xplr/discussions/183">Embedded LuaJIT</a> for

en/print.html

@@ -148,12 +148,12 @@
                 <div id="content" class="content">
                     <main>
                         <h1 id="introduction"><a class="header" href="#introduction">Introduction</a></h1>
-<p><code>xplr</code> is a terminal UI based file explorer that aims to increase our terminal
+<p>xplr is a terminal UI based file explorer that aims to increase our terminal
 productivity by being a flexible, interactive orchestrator for the ever growing
 awesome command-line utilities that work with the file-system.</p>
-<p>To achieve its goal, <code>xplr</code> strives to be a fast, minimal and more importantly,
+<p>To achieve its goal, xplr strives to be a fast, minimal and more importantly,
 hackable file explorer.</p>
-<p><code>xplr</code> is not meant to be a replacement for the standard shell commands or the
+<p>xplr is not meant to be a replacement for the standard shell commands or the
 GUI file managers. Rather, it aims to integrate them all and expose an
 intuitive, scriptable, keyboard controlled, real-time visual interface, also
 being an ideal candidate for further integration, enabling the users to achieve
@@ -162,31 +162,31 @@ insane terminal productivity.</p>
 <h3 id="hackable"><a class="header" href="#hackable">Hackable</a></h3>
 <p>xplr is built with configurability in mind. So it allows you to perform a vast
 set of operations and make it behave just the way you want.</p>
-<p>A few things you can do with the [<code>xplr</code>][xplr] configuration</p>
+<p>A few things you can do with the xplr configuration</p>
 <ul>
 <li><a href="layouts.html">Hack the layout</a></li>
 <li><a href="modes.html">Hack the key bindings</a></li>
 <li><a href="awesome-plugins.html">Extend with plugins</a></li>
 </ul>
 <h2 id="fast"><a class="header" href="#fast">Fast</a></h2>
-<p>Although speed is not the primary concern, [<code>xplr</code>][xplr] is already fast
-enough so that you can take it out for a walk into your <code>node_modules</code> or
-<code>/nix/store</code> any time you want. I currently
+<p>Although speed is not the primary concern, xplr is already fast enough so that
+you can take it out for a walk into your <code>node_modules</code> or <code>/nix/store</code> any
+time you want. I currently
 <a href="https://github.com/sayanarijit/xplr/tree/main/benches">measure the most commonly used operations</a>
 and I have seen it improve significantly over time, and it's only the start.</p>
 <p><strong>Tip:</strong> A quick and easy way to optimize UI rendering is reducing the number
 of columns in the table.</p>
-<p><strong>Note:</strong> If you feel [<code>xplr</code>][xplr] is not behaving at its optimal, this is
-probably because I am waiting for someone to complain. I want to avoid
-optimizing things I don't need to, because optimization often requires either
-complexity or feature sacrifice or both.</p>
+<p><strong>Note:</strong> If you feel xplr is not behaving at its optimal, this is probably
+because I am waiting for someone to complain. I want to avoid optimizing things
+I don't need to, because optimization often requires either complexity or
+feature sacrifice or both.</p>
 <h2 id="minimalist"><a class="header" href="#minimalist">Minimalist</a></h2>
-<p>[<code>xplr</code>][xplr] prefers to stay minimal, both in terms of features and binary
-size, but just like speed, minimalism isn't as aggressively pursued as
-configurability. If adding some feature, lines of code, or a dependency allows
-the users to be a little more productive or allows [<code>xplr</code>][xplr] to be a
-little more configurable, it will be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance will also be considered in the
-decision-making.</p>
+<p>xplr prefers to stay minimal, both in terms of features and binary size, but
+just like speed, minimalism isn't as aggressively pursued as configurability.
+If adding some feature, lines of code, or a dependency allows the users to be a
+little more productive or allows xplr to be a little more configurable, it will
+be considered. But of-course, the <code>bulk vs productivity gain per user</code> balance
+will also be considered in the decision-making.</p>
 <h2 id="other-features"><a class="header" href="#other-features">Other features</a></h2>
 <ul>
 <li><a href="https://github.com/sayanarijit/xplr/discussions/183">Embedded LuaJIT</a> for