rollback unwanted mass changes

doc/zmq.adoc

@@ -107,7 +107,7 @@ Sockets
 ~~~~~~~
 0MQ sockets present an abstraction of an asynchronous _message queue_, with the
 exact queueing semantics depending on the socket type in use. See
-* xref:zmq_socket.adoc[zmq_socket] for the socket types provided.
+xref:zmq_socket.adoc[zmq_socket] for the socket types provided.
 
 The following functions are provided to work with sockets:
 
@@ -139,7 +139,7 @@ Monitoring socket events::
 0MQ provides a mechanism for applications to multiplex input/output events over
 a set containing both 0MQ sockets and standard sockets. This mechanism mirrors
 the standard _poll()_ system call, and is described in detail in
-* xref:zmq_poll.adoc[zmq_poll] This API is deprecated, however.
+xref:zmq_poll.adoc[zmq_poll] This API is deprecated, however.
 
 There is a new DRAFT API with multiple zmq_poller_* function, which is described
 in xref:zmq_poller.adoc[zmq_poller]

doc/zmq_bind.adoc

@@ -28,11 +28,11 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an
 
 Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one
 semantics. The precise semantics depend on the socket type and are defined in
-* xref:zmq_socket.adoc[zmq_socket]
+xref:zmq_socket.adoc[zmq_socket]
 
 The 'ipc', 'tcp', 'vmci' and 'udp' transports accept wildcard addresses: see
-* xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_tcp.adoc[zmq_tcp], xref:zmq_vmci.adoc[zmq_vmci] and
-* xref:zmq_udp.adoc[zmq_udp] for details.
+xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_tcp.adoc[zmq_tcp], xref:zmq_vmci.adoc[zmq_vmci] and
+xref:zmq_udp.adoc[zmq_udp] for details.
 
 NOTE: the address syntax may be different for _zmq_bind()_ and _zmq_connect()_
 especially for the 'tcp', 'pgm' and 'epgm' transports.

doc/zmq_connect.adoc

@@ -28,7 +28,7 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an
 
 Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one
 semantics. The precise semantics depend on the socket type and are defined in
-* xref:zmq_socket.adoc[zmq_socket]
+xref:zmq_socket.adoc[zmq_socket]
 
 NOTE: for most transports and socket types the connection is not performed
 immediately but as needed by 0MQ. Thus a successful call to _zmq_connect()_
@@ -42,7 +42,7 @@ NOTE: following a _zmq_connect()_, for socket types except for ZMQ_ROUTER,
 the socket enters its normal 'ready' state. By contrast, following a
 _zmq_bind()_ alone, the socket enters a 'mute' state in which the socket
 blocks or drops messages according to the socket type, as defined in
-* xref:zmq_socket.adoc[zmq_socket] A ZMQ_ROUTER socket enters its normal 'ready' state
+xref:zmq_socket.adoc[zmq_socket] A ZMQ_ROUTER socket enters its normal 'ready' state
 for a specific peer only when handshaking is complete for that peer, which
 may take an arbitrary time.
 

doc/zmq_ctx_set.adoc

@@ -130,7 +130,7 @@ The 'ZMQ_ZERO_COPY_RECV' argument specifies whether the message decoder should
 use a zero copy strategy when receiving messages. The zero copy strategy can
 lead to increased memory usage in some cases. This option allows you to use the
 older copying strategy. You can query the value of this option with
-* xref:zmq_ctx_get.adoc[zmq_ctx_get] using the 'ZMQ_ZERO_COPY_RECV' option.
+xref:zmq_ctx_get.adoc[zmq_ctx_get] using the 'ZMQ_ZERO_COPY_RECV' option.
 NOTE: in DRAFT state, not yet available in stable releases.
 
 [horizontal]

doc/zmq_ctx_term.adoc

@@ -33,7 +33,7 @@ For further details regarding socket linger behaviour refer to the _ZMQ_LINGER_
 option in xref:zmq_setsockopt.adoc[zmq_setsockopt]
 
 This function replaces the deprecated functions xref:zmq_term.adoc[zmq_term] and
-* xref:zmq_ctx_destroy.adoc[zmq_ctx_destroy]
+xref:zmq_ctx_destroy.adoc[zmq_ctx_destroy]
 
 
 == RETURN VALUE

doc/zmq_getsockopt.adoc

@@ -380,7 +380,7 @@ ZMQ_LINGER: Retrieve linger period for socket shutdown
 The 'ZMQ_LINGER' option shall retrieve the linger period for the specified
 'socket'.  The linger period determines how long pending messages which have
 yet to be sent to a peer shall linger in memory after a socket is closed with
-* xref:zmq_close.adoc[zmq_close], and further affects the termination of the socket's
+xref:zmq_close.adoc[zmq_close], and further affects the termination of the socket's
 context with xref:zmq_ctx_term.adoc[zmq_ctx_term] The following outlines the different
 behaviours:
 

doc/zmq_inproc.adoc

@@ -12,7 +12,7 @@ sharing a single 0MQ 'context'.
 NOTE: No I/O threads are involved in passing messages using the 'inproc'
 transport. Therefore, if you are using a 0MQ 'context' for in-process messaging
 only you can initialise the 'context' with zero I/O threads. See
-* xref:zmq_init.adoc[zmq_init] for details.
+xref:zmq_init.adoc[zmq_init] for details.
 
 
 == ADDRESSING

doc/zmq_msg_recv.adoc

@@ -36,7 +36,7 @@ message or none at all. The total number of message parts is unlimited except
 by available memory.
 
 An application that processes multi-part messages must use the _ZMQ_RCVMORE_
-* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_msg_recv()_ to determine if
+xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_msg_recv()_ to determine if
 there are further parts to receive.
 
 

doc/zmq_pgm.adoc

@@ -21,7 +21,7 @@ The 'pgm' and 'epgm' transports can only be used with the 'ZMQ_PUB' and
 
 Further, PGM sockets are rate limited by default. For details, refer to the
 'ZMQ_RATE', and 'ZMQ_RECOVERY_IVL' options documented in
-* xref:zmq_setsockopt.adoc[zmq_setsockopt]
+xref:zmq_setsockopt.adoc[zmq_setsockopt]
 
 CAUTION: The 'pgm' transport implementation requires access to raw IP sockets.
 Additional privileges may be required on some operating systems for this
@@ -67,7 +67,7 @@ Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream
 of data where 0MQ messages are not necessarily aligned with PGM datagram
 boundaries and a single 0MQ message may span several PGM datagrams. This stream
 of data consists of 0MQ messages encapsulated in 'frames' as described in
-* xref:zmq_tcp.adoc[zmq_tcp]
+xref:zmq_tcp.adoc[zmq_tcp]
 
 
 PGM datagram payload

doc/zmq_recv.adoc

@@ -32,7 +32,7 @@ message or none at all. The total number of message parts is unlimited except
 by available memory.
 
 An application that processes multi-part messages must use the _ZMQ_RCVMORE_
-* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recv()_ to determine if
+xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recv()_ to determine if
 there are further parts to receive.
 
 == RETURN VALUE

doc/zmq_recvmsg.adoc

@@ -34,7 +34,7 @@ message or none at all. The total number of message parts is unlimited except
 by available memory.
 
 An application that processes multi-part messages must use the _ZMQ_RCVMORE_
-* xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recvmsg()_ to determine if
+xref:zmq_getsockopt.adoc[zmq_getsockopt] option after calling _zmq_recvmsg()_ to determine if
 there are further parts to receive.
 
 

doc/zmq_setsockopt.adoc

@@ -171,7 +171,7 @@ sockets, see xref:zmq_curve.adoc[zmq_curve] You can provide the key as 32 binary
 bytes, or as a 40-character string encoded in the Z85 encoding format and
 terminated in a null byte. The public key must always be used with the
 matching secret key. To generate a public/secret key pair, use
-* xref:zmq_curve_keypair.adoc[zmq_curve_keypair] To derive the public key from a secret key,
+xref:zmq_curve_keypair.adoc[zmq_curve_keypair] To derive the public key from a secret key,
 use xref:zmq_curve_public.adoc[zmq_curve_public]
 
 NOTE: an option value size of 40 is supported for backwards compatibility,
@@ -206,7 +206,7 @@ Applicable socket types:: all, when using TCP transport
 ZMQ_CURVE_SERVER: Set CURVE server role
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Defines whether the socket will act as server for CURVE security, see
-* xref:zmq_curve.adoc[zmq_curve] A value of '1' means the socket will act as
+xref:zmq_curve.adoc[zmq_curve] A value of '1' means the socket will act as
 CURVE server. A value of '0' means the socket will not act as CURVE
 server, and its security role then depends on other option settings.
 Setting this to '0' shall reset the socket security to NULL. When you
@@ -228,7 +228,7 @@ sockets, see xref:zmq_curve.adoc[zmq_curve] You can provide the key as 32 binary
 bytes, or as a 40-character string encoded in the Z85 encoding format and
 terminated in a null byte. This key must have been generated together with
 the server's secret key. To generate a public/secret key pair, use
-* xref:zmq_curve_keypair.adoc[zmq_curve_keypair]
+xref:zmq_curve_keypair.adoc[zmq_curve_keypair]
 
 NOTE: an option value size of 40 is supported for backwards compatibility,
 though is deprecated.
@@ -270,7 +270,7 @@ Applicable socket types:: ZMQ_DEALER, ZMQ_CLIENT and ZMQ_PEER
 ZMQ_GSSAPI_PLAINTEXT: Disable GSSAPI encryption
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Defines whether communications on the socket will be encrypted, see
-* xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means  that communications will be
+xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means  that communications will be
 plaintext.  A value of '0' means communications will be encrypted.
 
 [horizontal]
@@ -294,7 +294,7 @@ Applicable socket types:: all, when using TCP transport
 ZMQ_GSSAPI_SERVER: Set GSSAPI server role
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Defines whether the socket will act as server for GSSAPI security, see
-* xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means the socket will act as GSSAPI
+xref:zmq_gssapi.adoc[zmq_gssapi] A value of '1' means the socket will act as GSSAPI
 server. A value of '0' means the socket will act as GSSAPI client.
 
 [horizontal]
@@ -482,7 +482,7 @@ ZMQ_LINGER: Set linger period for socket shutdown
 The 'ZMQ_LINGER' option shall set the linger period for the specified 'socket'.
 The linger period determines how long pending messages which have yet to be
 sent to a peer shall linger in memory after a socket is disconnected with
-* xref:zmq_disconnect.adoc[zmq_disconnect] or closed with xref:zmq_close.adoc[zmq_close], and further
+xref:zmq_disconnect.adoc[zmq_disconnect] or closed with xref:zmq_close.adoc[zmq_close], and further
 affects the termination of the socket's context with xref:zmq_ctx_term.adoc[zmq_ctx_term]
 The following outlines the different behaviours:
 
@@ -585,7 +585,7 @@ Applicable socket types:: all, when using TCP transport
 ZMQ_PLAIN_SERVER: Set PLAIN server role
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Defines whether the socket will act as server for PLAIN security, see
-* xref:zmq_plain.adoc[zmq_plain] A value of '1' means the socket will act as
+xref:zmq_plain.adoc[zmq_plain] A value of '1' means the socket will act as
 PLAIN server. A value of '0' means the socket will not act as PLAIN
 server, and its security role then depends on other option settings.
 Setting this to '0' shall reset the socket security to NULL.

doc/zmq_socket.adoc

@@ -19,7 +19,7 @@ The newly created socket is initially unbound, and not associated with any
 endpoints. In order to establish a message flow a socket must first be
 connected to at least one endpoint with xref:zmq_connect.adoc[zmq_connect], or at least one
 endpoint must be created for accepting incoming connections with
-* xref:zmq_bind.adoc[zmq_bind]
+xref:zmq_bind.adoc[zmq_bind]
 
 .Key differences to conventional sockets
 Generally speaking, conventional sockets present a _synchronous_ interface to
@@ -85,7 +85,7 @@ will accept messages, queue them, and send them as rapidly as the network
 allows. The outgoing buffer limit is defined by the high water mark for the
 socket. If the outgoing buffer is full, or, for connection-oriented transports,
 if the ZMQ_IMMEDIATE option is set and there is no connected peer,
-* xref:zmq_send.adoc[zmq_send] will block.
+xref:zmq_send.adoc[zmq_send] will block.
 The 'ZMQ_CLIENT' socket will not drop messages.
 
 When a 'ZMQ_CLIENT' socket is connected to multiple 'ZMQ_SERVER' sockets,
@@ -616,7 +616,7 @@ peers, and each message received is fair-queued from all connected peers.
 When a 'ZMQ_DEALER' socket enters the 'mute' state due to having reached the
 high water mark for all peers, or, for connection-oriented transports, if the
 ZMQ_IMMEDIATE option is set and there are no peers at all, then any
-* xref:zmq_send.adoc[zmq_send] operations on the socket shall block until the mute state
+xref:zmq_send.adoc[zmq_send] operations on the socket shall block until the mute state
 ends or at least one peer becomes available for sending; messages are not discarded.
 
 When a 'ZMQ_DEALER' socket is connected to a 'ZMQ_REP' socket each message sent

doc/zmq_unbind.adoc

@@ -24,7 +24,7 @@ The 'endpoint' argument is as described in xref:zmq_bind.adoc[zmq_bind]
 Unbinding wild-card address from a socket
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When wild-card `*` 'endpoint' (described in xref:zmq_tcp.adoc[zmq_tcp],
-* xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_udp.adoc[zmq_udp] and xref:zmq_vmci.adoc[zmq_vmci]) was used in
+xref:zmq_ipc.adoc[zmq_ipc], xref:zmq_udp.adoc[zmq_udp] and xref:zmq_vmci.adoc[zmq_vmci]) was used in
 _zmq_bind()_, the caller should use real 'endpoint' obtained from the 
 ZMQ_LAST_ENDPOINT socket option to unbind this 'endpoint' from a socket.