More line wrapping, paragraph reflow

3 files changed, 25 insertions, 17 deletions

diff --git a/doc/bigint.txt b/doc/bigint.txt
index cf42726cc..7eb884039 100644
--- a/doc/bigint.txt
+++ b/doc/bigint.txt
@@ -95,7 +95,8 @@ Number theoretic functions available include:
   so it is much less likely that ``verify_prime`` will return a false positive
   than ``check_prime`` will.
 
-.. cpp:function BigInt random_prime(RandomNumberGenerator& rng, size_t bits, BigInt coprime = 1, size_t equiv = 1, size_t equiv_mod = 2)
+.. cpp:function BigInt random_prime(RandomNumberGenerator& rng, \
+   size_t bits, BigInt coprime = 1, size_t equiv = 1, size_t equiv_mod = 2)
 
   Return a random prime number of ``bits`` bits long that is
   relatively prime to ``coprime``, and equivalent to ``equiv`` modulo
diff --git a/doc/filters.txt b/doc/filters.txt
index fa4959699..a4e651952 100644
--- a/doc/filters.txt
+++ b/doc/filters.txt
@@ -506,13 +506,13 @@ Here's a example::
    pipe.end_msg();
 
 There are some requirements to using ``Keyed_Filter`` that you must
-follow. If you call ``set_key`` or ``set_iv`` on a filter that
-is owned by a ``Pipe``, you must do so while the ``Pipe`` is
-"unlocked". This refers to the times when no messages are being processed by
-``Pipe`` -- either before ``Pipe``'s ``start_msg`` is called, or
-after ``end_msg`` is called (and no new call to ``start_msg``
-has happened yet). Doing otherwise will result in undefined behavior, probably
-silently getting invalid output.
+follow. If you call ``set_key`` or ``set_iv`` on a filter that is
+owned by a ``Pipe``, you must do so while the ``Pipe`` is
+"unlocked". This refers to the times when no messages are being
+processed by ``Pipe`` -- either before ``Pipe``'s ``start_msg`` is
+called, or after ``end_msg`` is called (and no new call to
+``start_msg`` has happened yet). Doing otherwise will result in
+undefined behavior, probably silently getting invalid output.
 
 And remember: if you're resetting both values, reset the key *first*.
 
@@ -525,9 +525,11 @@ then call ``get_cipher``. You will pass the return value
 directly into a ``Pipe``. There are a couple different functions
 which do varying levels of initialization:
 
-.. cpp:function:: Keyed_Filter* get_cipher(std::string cipher_spec, SymmetricKey key, InitializationVector iv, Cipher_Dir dir)
+.. cpp:function:: Keyed_Filter* get_cipher(std::string cipher_spec, \
+   SymmetricKey key, InitializationVector iv, Cipher_Dir dir)
 
-.. cpp:function:: Keyed_Filter* get_cipher(std::string cipher_spec, SymmetricKey key, Cipher_Dir dir)
+.. cpp:function:: Keyed_Filter* get_cipher(std::string cipher_spec, \
+   SymmetricKey key, Cipher_Dir dir)
 
 The version that doesn't take an IV is useful for things that don't
 use them, like block ciphers in ECB mode, or most stream ciphers. If
diff --git a/doc/x509.txt b/doc/x509.txt
index 9c3730ccb..3375af8b4 100644
--- a/doc/x509.txt
+++ b/doc/x509.txt
@@ -187,7 +187,8 @@ Adding Certificates
 You can add new certificates to a certificate store using any of these
 functions:
 
-.. cpp:function:: void X509_Store::add_cert(const X509_Certificate& cert, bool trusted = false)
+.. cpp:function:: void X509_Store::add_cert(const X509_Certificate& cert, \
+   bool trusted = false)
 
 .. cpp:function:: void X509_Store::add_cert(DataSource& source)
 
@@ -403,7 +404,8 @@ On the other hand, you may have issued a CRL before. In that case, you will
 want to issue a new CRL that contains all previously revoked
 certificates, along with any new ones. This is done by calling
 
-.. cpp:function:: X509_CRL X509_CA::update_crl(const X509_CRL& old_crl, std::vector<CRL_Entry> new_revoked, size_t seconds_to_expiration = 0)
+.. cpp:function:: X509_CRL X509_CA::update_crl(const X509_CRL& old_crl, \
+   std::vector<CRL_Entry> new_revoked, size_t seconds_to_expiration = 0)
 
   Where ``X509_CRL`` is the last CRL this CA issued, and
   ``new_revoked`` is a list of any newly revoked certificates. The
@@ -433,7 +435,8 @@ Generating a new self-signed certificate can often be useful, for
 example when setting up a new root CA, or for use in email
 applications. The library provides a utility function for this:
 
-.. cpp:function:: X509_Certificate create_self_signed_cert(const X509_Cert_Options& opts, const Private_Key& key)
+.. cpp:function:: X509_Certificate create_self_signed_cert( \
+   const X509_Cert_Options& opts, const Private_Key& key)
 
 Where ``key`` is obviously the private key you wish to use (the public key,
 used in the certificate itself, is extracted from the private key), and
@@ -448,7 +451,8 @@ Creating PKCS #10 Requests
 Also in ``x509self.h``, there is a function for generating new PKCS #10
 certificate requests:
 
-.. cpp:function:: PKCS10_Request create_cert_req(const X509_Cert_Options& opts, const Private_Key& key)
+.. cpp:function:: PKCS10_Request create_cert_req( \
+   const X509_Cert_Options& opts, const Private_Key& key)
 
 This function acts quite similarly to ``create_self_signed_cert``,
 except it instead returns a PKCS #10 certificate request. After
@@ -492,9 +496,10 @@ year/month/day. The date must be specified, but you can omit the time
 or trailing parts of it, for example "2002/11/27 1:50" or
 "2002/11/27".
 
-Lastly, you can set constraints on a key. The one you're mostly likely to want
-to use is to create (or request) a CA certificate, which can be done by calling
-the member function ``CA_key``. This should only be used when needed.
+Lastly, you can set constraints on a key. The one you're mostly likely
+to want to use is to create (or request) a CA certificate, which can
+be done by calling the member function ``CA_key``. This should only be
+used when needed.
 
 Other constraints can be set by calling the member functions
 ``add_constraints`` and ``add_ex_constraints``. The