Adjust language.

diff --git a/blog/data/2023-01-08-linuxcnc-mqtt.txt b/blog/data/2023-01-08-linuxcnc-mqtt.txt
index 6d6c619c8917754f29ec0b28cf35be6f2eb364c4..7e3babb589eef1c9336d6293c2ff6647bfbe6bdb 100644 (file)
--- a/blog/data/2023-01-08-linuxcnc-mqtt.txt
+++ b/blog/data/2023-01-08-linuxcnc-mqtt.txt
@@ -9,19 +9,20 @@ information to the MQTT broker IBM Bluemix.  As I also use MQTT for
 graphing, it occured to me that a generic MQTT LinuxCNC component
 would be useful and I set out to implement it.  Today I got the first
 draft limping along and submitted as
-<ahref="https://github.com/LinuxCNC/linuxcnc/pull/2253">a patch to the
+<a href="https://github.com/LinuxCNC/linuxcnc/pull/2253">a patch to the
 LinuxCNC project</a>.</p>
 
 <p>The simple part was setting up the MQTT publishing code in Python.
 I already have set up other parts submitting data to my Mosquito MQTT
 broker, so I could reuse that code.  Writing a LinuxCNC component in
 Python as new to me, but using existing examples in the code
-repository, this was fairly straight forward.  The hardest part was
-creating a automated test for the component to ensure it was working.
-Testing it in a simulated LinuxCNC machine proved very useful, as I
-discovered features I needed that I had not thought of yet, and
-adjusted the code quite a bit to make it easier to test without a
-operational MQTT broker available.</p>
+repository and the extensive documentation, this was fairly straight
+forward.  The hardest part was creating a automated test for the
+component to ensure it was working.  Testing it in a simulated
+LinuxCNC machine proved very useful, as I discovered features I needed
+that I had not thought of yet, and adjusted the code quite a bit to
+make it easier to test without a operational MQTT broker
+available.</p>
 
 <p>The draft is ready and working, but I am unsure which LinuxCNC HAL
 pins I should collect and publish by default (in other words, the