Uses tagfiles in the antora documentation

doc/modules/ROOT/pages/auth.adoc

@@ -16,7 +16,7 @@ to customize this handshake by using a _setup request_: a request that
 is run automatically before any other request,
 every time a physical connection to the server is established.
 
-Configuration is done on xref:reference:boost/redis/config.adoc[`config`].
+Configuration is done on cpp:config[].
 Set `use_setup` to `true` (required for backwards compatibility)
 and build the desired setup request in
 `config::setup`. By default, the library sends a plain `HELLO 3` (RESP3

doc/modules/ROOT/pages/cancellation.adoc

@@ -8,7 +8,7 @@
 
 = Cancellation and timeouts
 
-By default, running a request with xref:reference:boost/redis/basic_connection/async_exec-02.adoc[`async_exec`]
+By default, running a request with cpp:basic_connection::async_exec[`async_exec`]
 will wait until a connection to the Redis server is established by `async_run`.
 This may take a very long time if the server is down.
 
@@ -63,8 +63,7 @@ If you know that a `request` object contains only idempotent commands,
 you can instruct Boost.Redis to retry the request on failure, even
 if the library is unsure about the server having processed the request or not.
 You can do so by setting `cancel_if_unresponded`
-in xref:reference:boost/redis/request/config.adoc[`request::config`]
-to false:
+in cpp:request::config[] to false:
 
 [source,cpp]
 ----

doc/modules/ROOT/pages/index.adoc

@@ -82,10 +82,10 @@ auto co_main(config const& cfg) -> net::awaitable<void>
 
 The roles played by the `async_run` and `async_exec` functions are:
 
-* xref:reference:boost/redis/basic_connection/async_exec-02.adoc[`connection::async_exec`]: executes the commands contained in the
+* cpp:basic_connection::async_exec[`connection::async_exec`]: executes the commands contained in the
   request and stores the individual responses in the response object. Can
   be called from multiple places in your code concurrently.
-* xref:reference:boost/redis/basic_connection/async_run-04.adoc[`connection::async_run`]: keeps the connection healthy. It takes care of hostname resolution, session establishment, health-checks, reconnection and coordination of low-level read and write operations. It should be called only once per connection, regardless of the number of requests to execute.
+* cpp:basic_connection::async_run[`connection::async_run`]: keeps the connection healthy. It takes care of hostname resolution, session establishment, health-checks, reconnection and coordination of low-level read and write operations. It should be called only once per connection, regardless of the number of requests to execute.
 
 
 == Further reading

doc/modules/ROOT/pages/logging.adoc

@@ -8,15 +8,15 @@
 
 = Logging
 
-xref:reference:boost/redis/basic_connection/async_run-04.adoc[`connection::async_run`]
+cpp:basic_connection::async_run[`connection::async_run`]
 is a complex algorithm, with features like built-in reconnection.
 This can make configuration problems, like a misconfigured hostname, difficult to debug -
 Boost.Redis will keep retrying to connect to the same hostname over and over.
 For this reason, Boost.Redis incorporates a lightweight logging solution, and
 *will log some status messages to stderr by default*.
 
 Logging can be customized by passing a
-xref:reference:boost/redis/logger.adoc[`logger`] object to the connection's constructor. For example, logging can be disabled by writing:
+cpp:logger[] object to the connection's constructor. For example, logging can be disabled by writing:
 
 [source,cpp]
 ----
@@ -26,7 +26,7 @@ connection conn {ioc, logger{logger::level::disabled}};
 
 Every message logged by the library is attached a
 https://en.wikipedia.org/wiki/Syslog#Severity_level[syslog-like severity]
-tag (a xref:reference:boost/redis/logger/level.adoc[`logger::level`]).
+tag (a cpp:logger::level[]).
 You can filter messages by severity by creating a `logger` with a specific level:
 
 [source,cpp]

doc/modules/ROOT/pages/pushes.adoc

@@ -65,21 +65,21 @@ auto receiver(std::shared_ptr<connection> conn) -> asio::awaitable<void>
 
 Summary of the steps:
 
-* Call xref:reference:boost/redis/basic_connection.adoc[`connection::set_receive_response`]
+* Call cpp:basic_connection::set_receive_response[`connection::set_receive_response`]
   before any other receive-related calls so that the connection stores incoming pushes in the
   given object. The library does not copy the response; you must keep it alive for the
   duration of the receive loop.
-* Build a request with xref:reference:boost/redis/request.adoc[`request::subscribe`]
+* Build a request with cpp:request::subscribe[]
   (or `psubscribe`) and execute it. If the connection drops and is re-established,
   an equivalent `SUBSCRIBE` is sent automatically.
-* Loop while xref:reference:boost/redis/basic_connection.adoc[`connection::will_reconnect`]
+* Loop while cpp:basic_connection::will_reconnect[`connection::will_reconnect`]
   is true (i.e. until the connection is cancelled).
-* Call xref:reference:boost/redis/basic_connection.adoc[`connection::async_receive2`]
+* Call cpp:basic_connection::async_receive2[`connection::async_receive2`]
   to wait until at least one push is available. This function also participates in
   push flow control (see <<flow-control>>).
 * After completion, `resp` holds the raw RESP3 nodes for the received pushes
-  (xref:reference:boost/redis/resp3/node_view.adoc[`resp3::node_view`]).
-  For Pub/Sub messages produced by `PUBLISH`, use xref:reference:boost/redis/push_parser.adoc[`push_parser`]
+  (cpp:resp3::node_view[]).
+  For Pub/Sub messages produced by `PUBLISH`, use cpp:push_parser[]
   to iterate over them. Each parsed message exposes the channel, the payload, and, for
   pattern subscriptions (`PSUBSCRIBE`), the matched pattern.
 * Call `resp.value().clear()` to discard the current push data and make room for the
@@ -94,7 +94,7 @@ traffic. Boost.Redis relies on RESP3 to multiplex them on a single connection.
 
 == Dynamic Pub/Sub tracking
 
-When you execute a request built with xref:reference:boost/redis/request.adoc[`request::subscribe`]
+When you execute a request built with cpp:request::subscribe[]
 (or `psubscribe`, `unsubscribe`, `punsubscribe`), the connection tracks it. After a reconnect, it
 re-issues the subscribe commands to restore any subscriptions that were active before the reconnect.
 You can dynamically subscribe and unsubscribe to channels; tracking is fully dynamic.
@@ -111,7 +111,7 @@ The pending count is reset each time `async_receive2` completes. You must still
 memory by calling `resp3::flat_tree::clear()` (or equivalent) on the response, as in
 the example.
 
-WARNING: Do not call xref:reference:boost/redis/basic_connection/async_exec-02.adoc[`async_exec`] from within the receiver loop. The response to your request may be behind enough pushes might to trigger the flow control mechanism, causing a deadlock.
+WARNING: Do not call cpp:basic_connection::async_exec[`async_exec`] from within the receiver loop. The response to your request may be behind enough pushes might to trigger the flow control mechanism, causing a deadlock.
 
 
 == Subscribe confirmations
@@ -124,7 +124,7 @@ As a result, *`async_receive2` will complete while the `push_parser` range is em
 when only confirmations are received. Your code should handle an empty range correctly.
 
 To work with subscribe confirmations or other push shapes, use the raw nodes in
-xref:reference:boost/redis/generic_flat_response.adoc[`generic_flat_response`]
+cpp:generic_flat_response[]
 directly (see <<advanced-scenarios>>).
 
 [#suspending-the-receiver]
@@ -166,7 +166,7 @@ co_await websocket.async_write(msg);
 
 `SUBSCRIBE` can fail (e.g. due to ACL rules). Because of how the protocol works, such
 errors may be delivered as push-like data. Using
-xref:reference:boost/redis/generic_flat_response.adoc[`generic_flat_response`]
+cpp:generic_flat_response[]
 (an alias for `adapter::result<resp3::flat_tree>`, similar to `std::expected`) lets you detect them: check
 `resp.has_error()` and handle the error before iterating. See the example at the top
 of this page.

doc/modules/ROOT/pages/reference.adoc

@@ -19,90 +19,90 @@
 | *Unstable low-level APIs*
 
 |
-xref:reference:boost/redis/connection.adoc[`connection`]
+cpp:connection[]
 
-xref:reference:boost/redis/basic_connection.adoc[`basic_connection`]
+cpp:basic_connection[]
 
-xref:reference:boost/redis/address.adoc[`address`]
+cpp:address[]
 
-xref:reference:boost/redis/role.adoc[`role`]
+cpp:role[]
 
-xref:reference:boost/redis/config.adoc[`config`]
+cpp:config[]
 
-xref:reference:boost/redis/sentinel_config.adoc[`sentinel_config`]
+cpp:sentinel_config[]
 
-xref:reference:boost/redis/error.adoc[`error`]
+cpp:error[]
 
-xref:reference:boost/redis/logger.adoc[`logger`]
+cpp:logger[]
 
-xref:reference:boost/redis/logger/level.adoc[`logger::level`]
+cpp:logger::level[]
 
-xref:reference:boost/redis/operation.adoc[`operation`]
+cpp:operation[]
 
-xref:reference:boost/redis/usage.adoc[`usage`]
+cpp:usage[]
 
 
 |
-xref:reference:boost/redis/ignore_t.adoc[`ignore_t`]
+cpp:ignore_t[]
 
-xref:reference:boost/redis/ignore.adoc[`ignore`]
+cpp:ignore[]
 
-xref:reference:boost/redis/request.adoc[`request`]
+cpp:request[]
 
-xref:reference:boost/redis/request/config.adoc[`request::config`]
+cpp:request::config[]
 
-xref:reference:boost/redis/response.adoc[`response`]
+cpp:response[]
 
-xref:reference:boost/redis/generic_response.adoc[`generic_response`]
+cpp:generic_response[]
 
-xref:reference:boost/redis/generic_flat_response.adoc[`generic_flat_response`]
+cpp:generic_flat_response[]
 
-xref:reference:boost/redis/consume_one-08.adoc[`consume_one`]
+cpp:consume_one[]
 
-xref:reference:boost/redis/push_view.adoc[`push_view`]
+cpp:push_view[]
 
-xref:reference:boost/redis/push_parser.adoc[`push_parser`]
+cpp:push_parser[]
 
 
 |
-xref:reference:boost/redis/adapter/boost_redis_adapt.adoc[`boost_redis_adapt`]
+cpp:adapter::boost_redis_adapt[`boost_redis_adapt`]
 
-xref:reference:boost/redis/adapter/ignore.adoc[`adapter::ignore`]
+cpp:adapter::ignore[]
 
-xref:reference:boost/redis/adapter/error.adoc[`adapter::error`]
+cpp:adapter::error[]
 
-xref:reference:boost/redis/adapter/result.adoc[`adapter::result`]
+cpp:adapter::result[]
 
-xref:reference:boost/redis/any_adapter.adoc[`any_adapter`]
+cpp:any_adapter[]
 
 |
-xref:reference:boost/redis/resp3/basic_node.adoc[`resp3::basic_node`]
+cpp:resp3::basic_node[]
 
-xref:reference:boost/redis/resp3/node.adoc[`resp3::node`]
+cpp:resp3::node[]
 
-xref:reference:boost/redis/resp3/node_view.adoc[`resp3::node_view`]
+cpp:resp3::node_view[]
 
-xref:reference:boost/redis/resp3/basic_tree.adoc[`resp3::basic_tree`]
+cpp:resp3::basic_tree[]
 
-xref:reference:boost/redis/resp3/tree.adoc[`resp3::tree`]
+cpp:resp3::tree[]
 
-xref:reference:boost/redis/resp3/view_tree.adoc[`resp3::view_tree`]
+cpp:resp3::view_tree[]
 
-xref:reference:boost/redis/resp3/flat_tree.adoc[`resp3::flat_tree`]
+cpp:resp3::flat_tree[]
 
-xref:reference:boost/redis/resp3/boost_redis_to_bulk-08.adoc[`boost_redis_to_bulk`]
+cpp:resp3::boost_redis_to_bulk[`boost_redis_to_bulk`]
 
-xref:reference:boost/redis/resp3/type.adoc[`resp3::type`]
+cpp:resp3::type[]
 
-xref:reference:boost/redis/resp3/is_aggregate.adoc[`resp3::is_aggregate`]
+cpp:resp3::is_aggregate[]
 
 
 |
 
-xref:reference:boost/redis/adapter/adapt2.adoc[`adapter::adapt2`]
+cpp:adapter::adapt2[]
 
-xref:reference:boost/redis/resp3/parser.adoc[`resp3::parser`]
+cpp:resp3::parser[]
 
-xref:reference:boost/redis/resp3/parse.adoc[`resp3::parse`]
+cpp:resp3::parse[]
 
 |===

doc/modules/ROOT/pages/requests_responses.adoc

@@ -36,18 +36,18 @@ req.push_range("HSET", "key", map);
 ----
 
 Sending a request to Redis is performed by
-xref:reference:boost/redis/basic_connection/async_exec-02.adoc[`connection::async_exec`]
-as already stated. Requests accept a xref:reference:boost/redis/request/config.adoc[`boost::redis::request::config`]
+cpp:basic_connection::async_exec[`connection::async_exec`]
+as already stated. Requests accept a cpp:request::config[]
 object when constructed that dictates how requests are handled in situations like
 reconnection. The reader is advised to read it carefully.
 
 ## Responses
 
 Boost.Redis uses the following strategy to deal with Redis responses:
 
-* xref:reference:boost/redis/response.adoc[`boost::redis::response`] should be used
+* cpp:response[] should be used
   when the request's number of commands is known at compile-time.
-* xref:reference:boost/redis/generic_response.adoc[`boost::redis::generic_response`] should be
+* cpp:generic_response[] should be
   used when the number of commands is dynamic.
 
 For example, the request below has three commands:
@@ -74,7 +74,7 @@ It is also necessary that each tuple element is capable of storing the
 response to the command it refers to, otherwise an error will occur.
 
 To ignore responses to individual commands in the request use the tag
-xref:reference:boost/redis/ignore_t.adoc[`boost::redis::ignore_t`]. For example:
+cpp:ignore_t[]. For example:
 
 [source,cpp]
 ----
@@ -148,15 +148,15 @@ response<
 ----
 
 To execute the request and read the response use
-xref:reference:boost/redis/basic_connection/async_exec-02.adoc[`async_exec`]:
+cpp:basic_connection::async_exec[`async_exec`]:
 
 [source,cpp]
 ----
 co_await conn->async_exec(req, resp);
 ----
 
 If the intention is to ignore responses altogether, use
-xref:reference:boost/redis/ignore.adoc[`ignore`]:
+cpp:ignore[]:
 
 [source,cpp]
 ----
@@ -254,7 +254,7 @@ commands won't fit in the model presented above. Some examples are:
 * RESP3 aggregates that contain nested aggregates can't be read in STL containers.
 * Transactions with a dynamic number of commands can't be read in a `response`.
 
-To deal with these cases Boost.Redis provides the xref:reference:boost/redis/resp3/node.adoc[`boost::redis::resp3::node`] type
+To deal with these cases Boost.Redis provides the cpp:resp3::node[] type
 abstraction, that is the most general form of an element in a
 response, be it a simple RESP3 type or the element of an aggregate. It
 is defined like:
@@ -277,9 +277,8 @@ struct basic_node {
 };
 ----
 
-Any response to a Redis command can be parsed into a
-xref:reference:boost/redis/generic_response.adoc[boost::redis::generic_response]
-and its counterpart xref:reference:boost/redis/generic_flat_response.adoc[boost::redis::generic_flat_response].
+Any response to a Redis command can be parsed into a cpp:generic_response[]
+and its counterpart cpp:generic_flat_response[].
 The vector can be seen as a pre-order view of the response tree.
 Using it is not different than using other types:
 

doc/modules/ROOT/pages/sentinel.adoc

@@ -9,10 +9,10 @@
 = Sentinel
 
 Boost.Redis supports Redis Sentinel deployments. Sentinel handling
-in `connection` is built-in: xref:reference:boost/redis/basic_connection/async_run-04.adoc[`async_run`]
+in `connection` is built-in: cpp:basic_connection::async_run[`async_run`]
 automatically connects to Sentinels, resolves the master's address, and connects to the master.
 
-Configuration is done using xref:reference:boost/redis/sentinel_config.adoc[`config::sentinel`]:
+Configuration is done using cpp:sentinel_config[`config::sentinel`]:
 
 [source,cpp]
 ----
@@ -39,7 +39,7 @@ for a full program.
 
 By default, the library connects to the Redis master.
 You can connect to one of its replicas by using
-xref:reference:boost/redis/sentinel_config/server_role.adoc[`config::sentinel::server_role`].
+cpp:sentinel_config::server_role[`config::sentinel::server_role`].
 This can be used to balance load, if all your commands read data from
 the server and never write to it. The particular replica will be chosen randomly.
 
@@ -63,7 +63,7 @@ cfg.sentinel.server_role = role::replica;
 == Sentinel authentication
 
 If your Sentinels require authentication, 
-you can use xref:reference:boost/redis/sentinel_config/setup.adoc[`config::sentinel::setup`]
+you can use cpp:sentinel_config::setup[`config::sentinel::setup`]
 to provide credentials.
 This request is executed immediately after connecting to Sentinels, and
 before any other command:
@@ -94,8 +94,8 @@ cfg.setup.push("HELLO", 3, "AUTH", "master_user", "master_password");
 == Using TLS with Sentinels
 
 You might use TLS with Sentinels only, masters/replicas only, or both by adjusting
-xref:reference:boost/redis/sentinel_config/use_ssl.adoc[`config::sentinel::use_ssl`]
-and xref:reference:boost/redis/config/use_ssl.adoc[`config::use_ssl`]:
+cpp:sentinel_config::use_ssl[`config::sentinel::use_ssl`]
+and cpp:config::use_ssl[]:
 
 [source,cpp]
 ----
@@ -121,7 +121,7 @@ https://redis.io/docs/latest/develop/reference/sentinel-clients/[the official Se
 Some of these details may vary between library versions.
 
 * Connections maintain an internal list of Sentinels, bootstrapped from
-  xref:reference:boost/redis/sentinel_config/addresses.adoc[`config::sentinel::addresses`].
+  cpp:sentinel_config::addresses[`config::sentinel::addresses`].
 * The first Sentinel in the list is contacted by performing the following:
 ** A physical connection is established.
 ** The setup request is executed.