From 9cbb446198163c13bab7447ad330cb046385d026 Mon Sep 17 00:00:00 2001
From: Paul Buetow <paul@buetow.org>
Date: Mon, 17 Jul 2023 20:24:53 +0300
Subject: Update content for html

---
 gemfeed/2022-05-27-perl-is-still-a-great-choice.html    |  2 +-
 gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.html | 16 ++++++++++++++++
 2 files changed, 17 insertions(+), 1 deletion(-)

(limited to 'gemfeed')

diff --git a/gemfeed/2022-05-27-perl-is-still-a-great-choice.html b/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
index 3a32639b..1af9a949 100644
--- a/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
+++ b/gemfeed/2022-05-27-perl-is-still-a-great-choice.html
@@ -117,7 +117,7 @@
 <span>Here are some reasons why not to chose Perl and look for "better" alternatives:</span><br />
 <br />
 <ul>
-<li>If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or gradually typed languages run in a VM (e.g. Raku) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java or faster regular expressions engine), but usually it&#39;s not. It&#39;s not a problem of Perl, it&#39;s a problem of all dynamic scripting languages including Python, Ruby, ....</li>
+<li>If performance is your main objectives, then Perl might not be the language to use. Perl is a dynamic interpreted language, and it will generally never be as fast as statically typed languages compiled to native binaries (e.g. C/C++/Rust/Haskell) or statically typed languages run in a VM with JIT (e.g. Java) or languages like Golang (statically typed, compiled to a binary but still with a runtime in the binary). Perl might be still faster than the other language listed here in certain circumstances (e.g. faster startup time than Java or faster regular expressions engine), but usually it&#39;s not. It&#39;s not a problem of Perl, it&#39;s a problem of all dynamic scripting languages including Python, Ruby, ....</li>
 <li>Don&#39;t use Perl (just yet) if you want to code object-oriented. Perl supports OOP, but it feels clunky and odd to use (blessed references to any data types are objects) and doesn&#39;t support real encapsulation out of the box. There are many (many) extensions available on CPAN to make OOP better, but that&#39;s totally fragmented. The most popular extension, Moose, comes with a huge dependency tree. But wait for Perl 7. It will maybe come with a new object system (an object system inspired by Raku).</li>
 <li>It&#39;s possible to write large programs in Perl (make difficult things possible), but it might not be the best choice here. This also leads back to the clunky object system Perl has. You could write your projects in a procedural or functional style (Perl perfectly fits here), but OOP seems to be the gold standard for large projects nowadays. Functional programming requires a different mindset, and pure procedural programming lacks abstractions.</li>
 <li>Apply common sense. What is the skill set your team has? What&#39;s already widely used and supported at work? Which languages comes with the best modules for the things you want to work on? Maybe Python is the answer (better machine learning modules). Maybe Perl is the better choice (better Bioinformatic modules). Perhaps Ruby is already the de-facto standard at work and everyone knows at least a little Ruby (as it happened to be at my workplace) and Ruby is "good enough" for all the tasks already. But that&#39;s not a hindrance to throw in a Perl one-liner once in a while :P.</li>
diff --git a/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.html b/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.html
index 94d07bfd..d467d521 100644
--- a/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.html
+++ b/gemfeed/DRAFT-gemtexter-2.1.0-lets-gemtext-again-3.html
@@ -31,10 +31,26 @@
 <br />
 <h2 style='display: inline'>Switch to GPL3 license</h2><br />
 <br />
+<span>Many of the tools and commands (GNU Bash, GMU Sed, GNU Date, GNU Grep, GNU Source Highlight) used by <span class='inlinecode'>Gemtexter</span> are licensed under the GPL anyway. So why not use the same? This was an easy switch, as I was the only code contributor so far!</span><br />
+<br />
 <h2 style='display: inline'>Source code highlighting support</h2><br />
 <br />
+<span>The HTML output now supports source code highlighting, which is pretty neat if your site is about programming. The requirement is to have the <span class='inlinecode'>source-highlight</span> command, which is GNU Source Highlight, to be installed. Once done, you can annotate a bare block with the language to be highlighted. E.g.:</span><br />
+<br />
+<pre>
+ ```bash
+ if [ -n "$foo" ]; then
+   echo "$foo"
+ fi
+ ...
+</pre>
+<br />
+<span>Please run <span class='inlinecode'>source-highlight --lang-list</span> for a list of all supported languages.</span><br />
+<br />
 <h2 style='display: inline'>HTML exact style</h2><br />
 <br />
+<span>The resulting HTML has changed.</span><br />
+<br />
 <h3 style='display: inline'>Use of Hack webfont by default</h3><br />
 <br />
 <h2 style='display: inline'>Mastadon verification support</h2><br />
-- 
cgit v1.2.3