Language cleanups in the documentation.

Mostly this is removal of the smart quotes, which were
over-used, and misused, and could have been mistaken to
be pejorative.  A few other minor nits were fixed while here.

1 files changed, 4 insertions, 4 deletions

diff --git a/docs/man/nng_req.7.adoc b/docs/man/nng_req.7.adoc
index ada83c65..28765083 100644
--- a/docs/man/nng_req.7.adoc
+++ b/docs/man/nng_req.7.adoc
@@ -40,7 +40,7 @@ some reason.)
 
 (((load-balancing)))
 The requester generally only has one outstanding request at a time unless
-in "`raw`" mode (via
+in raw mode (via
 xref:nng_options.5.adoc#NNG_OPT_RAW[`NNG_OPT_RAW`]),
 and it will generally attempt to spread work requests to different peer repliers.
 
@@ -109,7 +109,7 @@ The following protocol-specific option is available.
 
 (((backtrace)))
 This protocol uses a _backtrace_ in the header.
-This form uses a "`stack`" of 32-bit big-endian identifiers.
+This form uses a stack of 32-bit big-endian identifiers.
 There *must* be at least one identifier, the __request ID__, which will be the
 last element in the array, and *must* have the most significant bit set.
 
@@ -125,7 +125,7 @@ peer from which it received the message.
 (This peer ID, except for the
 most significant bit, has meaning only to the forwarding node itself.)
 
-It may help to think of prepending a peer ID as "`pushing`" a peer ID onto the
+It may help to think of prepending a peer ID as pushing a peer ID onto the
 front of the stack of headers for the message.
 (It will use the peer ID
 it popped from the front to determine the next intermediate destination
@@ -134,7 +134,7 @@ for the reply.)
 When a reply message is created, it is created using the same headers
 that the request contained.
 
-A forwarding node can "`pop`" the peer ID it originally pushed on the
+A forwarding node can pop the peer ID it originally pushed on the
 message, stripping it from the front of the message as it does so.
 
 When the reply finally arrives back at the initiating requester, it