Replace backticks with <literal>

man/flashmq.conf.5

@@ -5,7 +5,7 @@
 \\$2 \(la\\$1\(ra\\$3
 ..
 .if \n(.g .mso www.tmac
-.TH flashmq.conf 5 "Nov 07 2024" "" ""
+.TH flashmq.conf 5 "Nov 08 2024" "" ""
 .SH NAME
 flashmq.conf \- FlashMQ configuration file format
 .SH SYNOPSIS
@@ -241,9 +241,9 @@ Default value: \fI\m[blue]4294967296\m[]\fR
 Deprecated.
 .TP
 \*(T<\fB\m[green]retained_messages_node_limit\m[] \fI\m[cyan]number\m[]\fR\fR\*(T>
-When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to `#`, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed.
+When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to \fI#\fR, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed.
 
-Note that the topic `one/two/three` is three nodes, and each node doesn't necessarilly need to contain a message.
+Note that the topic \fIone/two/three\fR is three nodes, and each node doesn't necessarilly need to contain a message.
 
 Default value: \fI\m[blue]4294967296\m[]\fR
 .TP

man/flashmq.conf.5.dbk5

@@ -486,10 +486,10 @@ multi-value-param one 'two' "three" "with ' char"
         <term><option>retained_messages_node_limit</option> <replaceable>number</replaceable></term>
         <listitem>
           <para>
-            When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to `#`, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed. 
+            When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to <literal>#</literal>, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed.
           </para>
           <para>
-            Note that the topic `one/two/three` is three nodes, and each node doesn't necessarilly need to contain a message.
+            Note that the topic <literal>one/two/three</literal> is three nodes, and each node doesn't necessarilly need to contain a message.
           </para>
           <para>
             Default value: <filename>4294967296</filename>
@@ -504,7 +504,7 @@ multi-value-param one 'two' "three" "with ' char"
             The time after which FlashMQ will fall back to (b)locking vs queued mode for setting retained messages. 0, the default, disables queued mode altogether. It's disabled by default because it can incur some extra CPU and memory overhead.
           </para>
           <para>
-            Each retained message lives in a node in a tree. The topic 'one/two/three' is three nodes. When a node in that tree does not exist yet, it needs to be created. This requires a write lock on the tree. At this point, other threads reading from or writing to the retained message tree need to wait. This can cause a compounding blocking effect, especially if many threads do it at once. 
+            Each retained message lives in a node in a tree. The topic 'one/two/three' is three nodes. When a node in that tree does not exist yet, it needs to be created. This requires a write lock on the tree. At this point, other threads reading from or writing to the retained message tree need to wait. This can cause a compounding blocking effect, especially if many threads do it at once.
           </para>
           <para>
             This feature is to favor server responsiveness vs the speed at which retained messages become available in the server. It is primarily useful for when you have a lot of retained messages on different/changing topics. If at first a retained message can't be set, the action to do so will be retried in the event loop, asynchronously.

man/flashmq.conf.5.html

@@ -701,10 +701,10 @@
         <dt id="retained_messages_node_limit"><div xmlns="http://docbook.org/ns/docbook" class="flashmq_version_requirement" data-since-flashmq-version="1.8.4">≥ v1.8.4</div><code class="option">retained_messages_node_limit</code> <code class="replaceable">number</code><a class="hash-anchor" href="#retained_messages_node_limit">#</a></dt>
         <dd>
           <p>
-            When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to `#`, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed. 
+            When clients place a subscription, they will get the retained messages matching that subscription. Even though traversing the retained message tree is deprioritized in favor of other traffic, it will still cause CPU load until it's done. If you have a tree with millions of nodes and clients subscribe to <code class="literal">#</code>, this is potentially unwanted. You can use this setting to limit how many nodes of the retrained tree are traversed.
           </p>
           <p>
-            Note that the topic `one/two/three` is three nodes, and each node doesn't necessarilly need to contain a message.
+            Note that the topic <code class="literal">one/two/three</code> is three nodes, and each node doesn't necessarilly need to contain a message.
           </p>
           <p>
             Default value: <code class="filename">4294967296</code>
@@ -719,7 +719,7 @@
             The time after which FlashMQ will fall back to (b)locking vs queued mode for setting retained messages. 0, the default, disables queued mode altogether. It's disabled by default because it can incur some extra CPU and memory overhead.
           </p>
           <p>
-            Each retained message lives in a node in a tree. The topic 'one/two/three' is three nodes. When a node in that tree does not exist yet, it needs to be created. This requires a write lock on the tree. At this point, other threads reading from or writing to the retained message tree need to wait. This can cause a compounding blocking effect, especially if many threads do it at once. 
+            Each retained message lives in a node in a tree. The topic 'one/two/three' is three nodes. When a node in that tree does not exist yet, it needs to be created. This requires a write lock on the tree. At this point, other threads reading from or writing to the retained message tree need to wait. This can cause a compounding blocking effect, especially if many threads do it at once.
           </p>
           <p>
             This feature is to favor server responsiveness vs the speed at which retained messages become available in the server. It is primarily useful for when you have a lot of retained messages on different/changing topics. If at first a retained message can't be set, the action to do so will be retried in the event loop, asynchronously.