RST references like ``code``

src/vdp_pesi.vcc

@@ -69,7 +69,7 @@ include in a response before the first one. If the logic of ESI
 composition in a standard Varnish deployment does not depend on the
 serial order, then it will work the same way with VDP pesi.
 
-Parallel ESI processing is enabled by invoking `pesi.activate()`_ in
+Parallel ESI processing is enabled by invoking |pesi.activate()|_ in
 ``vcl_deliver {}``::
 
    import pesi;
@@ -84,10 +84,10 @@ Parallel ESI processing is enabled by invoking `pesi.activate()`_ in
 
 Other functions provided by the VDP serve to set configuration
 parameters (or return the VDP version string). If your deployment uses
-the default configuration, then `pesi.activate()`_ in ``vcl_deliver``
+the default configuration, then |pesi.activate()|_ in ``vcl_deliver``
 may be the only modification to VCL that you need.
 
-The invocation of `pesi.activate()`_ can of course be subject to
+The invocation of |pesi.activate()|_ can of course be subject to
 logic in VCL::
 
    sub vcl_deliver {
@@ -97,7 +97,7 @@ logic in VCL::
        }
    }
 
-But see below for restrictions on the use of `pesi.activate()`_.
+But see below for restrictions on the use of |pesi.activate()|_.
 
 All of the computing resources used by the pesi VDP -- threads, storage,
 workspace, locks, and so on -- can be configured, either with Varnish
@@ -130,7 +130,7 @@ others. Under no circumstances should the invocation of ``pesi.activate()``
 depend on the value of ``req.esi_level``, or of ``req.url`` (since
 URLs are different at different ESI levels).
 
-See `pesi.set()`_ below for a way to choose serial
+See |pesi.set()|_ below for a way to choose serial
 ESI processing for all of the includes in the response at the current
 ESI level. Even then, ``pesi.activate()`` must be called in ``vcl_deliver
 {}`` in addition to ``pesi.set()``.
@@ -402,7 +402,7 @@ allocation requests, even if ``max`` is execeeded when nodes are
 returned to the pool. But the pool size will then be reduced to
 ``max``, without waiting for ``max_age`` to expire.
 
-As with `pesi.workspace_prealloc()`_: when ``pesi.pool()`` is called, the
+As with |pesi.workspace_prealloc()|_: when ``pesi.pool()`` is called, the
 changed configuration immediately becomes valid (although it may take
 some time for the memory pool to adjust to the new values). It remains
 vaild for as long as the VDP is still loaded, unless ``pesi.pool()`` is
@@ -520,14 +520,14 @@ that is immediately ready for use.
 The VDP uses client workspace at the top-level request (ESI level 0)
 for fixed-sized internal metadata. It also uses client workspace to
 pre-allocate a constant number of nodes in variable-sized structures,
-as described in `pesi.workspace_prealloc()`_ above.  Together these
+as described in |pesi.workspace_prealloc()|_ above.  Together these
 make for a fixed-sized demand on client workspace, when
-`pesi.activate()`_ is invoked. The size of the space needed from
+|pesi.activate()|_ is invoked. The size of the space needed from
 workspace varies on different systems, and depends on
-`pesi.workspace_prealloc()`_ setting, but broadly speaking, it can
+|pesi.workspace_prealloc()|_ setting, but broadly speaking, it can
 expected to be less than 10 KiB.
 
-As described for `pesi.pool()`_, the VDP uses a memory pool for
+As described for |pesi.pool()|_, the VDP uses a memory pool for
 nodes in its internal reconstruction of the ESI tree, if more are
 needed than are pre-allocated in workspace. The same mechanism is
 employed as Varnish's memory pools, so the same considerations apply
@@ -757,6 +757,11 @@ See `INSTALL.rst <INSTALL.rst>`_ in the source repository.
 SEE ALSO
 ========
 
+.. |pesi.activate()| replace:: ``pesi.activate()``
+.. |pesi.set()| replace:: ``pesi.set()``
+.. |pesi.workspace_prealloc()| replace:: ``pesi.workspace_prealloc()``
+.. |pesi.pool()| replace:: ``pesi.pool()``
+
 .. _Content composition with Edge Side Includes: https://varnish-cache.org/docs/trunk/users-guide/esi.html
 
 * `varnishd(1)`_