addressing warnings and error in compilation

10 files changed, 27 insertions, 25 deletions

diff --git a/api-bank.rst b/api-bank.rst
index afb2ba28..48b7075e 100644
--- a/api-bank.rst
+++ b/api-bank.rst
@@ -35,10 +35,10 @@ namely exchanges.
 
 **Response:**
 
-:status 200 OK: The request has been correctly handled, so the funds have been transferred to
-the recipient's account
+:status 200 OK: The request has been correctly handled, so the funds have been transferred to the recipient's account
 
 :status 400 Bad Request: The bank replies a `BankIncomingError`_ object
+
 **Details:**
 
 .. _BankDepositRequest:
diff --git a/api-exchange.rst b/api-exchange.rst
index 63ac477c..3087a8e8 100644
--- a/api-exchange.rst
+++ b/api-exchange.rst
@@ -233,8 +233,7 @@ Obtaining wire-transfer information
       // A single /wire response can contain an arbitrary number of these
       // string-object pairs.  However, the keys must be unique.
       string : Object;
-
-    }
+     }
 
   Possible encodings for the objects are right now the following:
 
@@ -242,7 +241,7 @@ Obtaining wire-transfer information
   .. _tsref-type-WireTestResponse:
   .. code-block:: tsref
 
-  interface WireTestResponse {
+    interface WireTestResponse {
       // Mandatory indicator that this is a TEST wire response.
       type: "test";
 
@@ -251,14 +250,13 @@ Obtaining wire-transfer information
 
       // URI of the bank
       bank_uri: string;
-
     }
 
-      .. _WireSepaResponse:
+  .. _WireSepaResponse:
   .. _tsref-type-WireSepaResponse:
   .. code-block:: tsref
 
-  interface WireSepaResponse {
+    interface WireSepaResponse {
       // Mandatory indicator that this is a SEPA wire response.
       type: "sepa";
 
@@ -271,13 +269,12 @@ Obtaining wire-transfer information
       // BIC of the bank.
       bic: string;
 
-      // the EdDSA signature_ (binary-only) with purpose
+      // the EdDSA signature (binary-only) with purpose
       // `TALER_SIGNATURE_EXCHANGE_PAYMENT_METHOD_SEPA` signing over the hash over the
       // 0-terminated strings representing the receiver's name, IBAN and the BIC.
       sig: EddsaSignature;
     }
 
-
 ------------------
 Withdrawal
 ------------------
@@ -445,9 +442,9 @@ exchange.
 
 .. _deposit-par:
 
---------------------
+-------
 Deposit
---------------------
+-------
 
 Deposit operations are requested by a merchant during a transaction. For the
 deposit operation, the merchant has to obtain the deposit permission for a coin
@@ -543,9 +540,9 @@ denomination.
   has enough residual value that has not already been deposited or melted.
 
 
+  .. _DepositSuccess:
   .. code-block:: tsref
 
-     .. _DepositSuccess:
      interface DepositSuccess {
       // The string constant "DEPOSIT_OK"
       status: string;
@@ -562,7 +559,7 @@ denomination.
       // explicitly as the client might otherwise be confused by clock skew as to
       // which signing key was used.
       pub: EddsaPublicKey;
-    }
+      }
 
   .. _DepositDoubleSpendError:
   .. code-block:: tsref
@@ -1150,10 +1147,10 @@ Refunds
 
     }
 
+  .. _RefundSuccess:
   .. code-block:: tsref
 
-     .. _RefundSuccess:
-     interface RefundSuccess {
+    interface RefundSuccess {
       // The string constant "REFUND_OK"
       status: string;
 
@@ -1167,7 +1164,7 @@ Refunds
       // explicitly as the client might otherwise be confused by clock skew as to
       // which signing key was used.
       pub: EddsaPublicKey;
-    }
+   }
 
 ------------------------------
 Administrative API: Key update
diff --git a/api-merchant.rst b/api-merchant.rst
index ff347979..8815e750 100644
--- a/api-merchant.rst
+++ b/api-merchant.rst
@@ -228,6 +228,7 @@ The following API are made available by the merchant's `backend` to the merchant
 
   :query id: ID of the transaction we want to trace (an integer)
   :query receiver: identificative token for the merchant instance which is to be tracked (optional). See :ref:`instances`.
+
   **Response:**
 
   :status 200 OK:
diff --git a/dev-merchant.rst b/dev-merchant.rst
index bb809128..cb834659 100644
--- a/dev-merchant.rst
+++ b/dev-merchant.rst
@@ -22,6 +22,7 @@ Introduction
 TBD
 
 .. _merchant-arch:
+
 ------
 Design
 ------
diff --git a/dev-wallet-wx.rst b/dev-wallet-wx.rst
index 5995226e..8ba29975 100644
--- a/dev-wallet-wx.rst
+++ b/dev-wallet-wx.rst
@@ -170,12 +170,14 @@ Internationalisation
 Strings in the JavaScript code are internationalised using the following functions:
 
 - *i18n*: translate string with arbitrary arguments, the result is returned as string.
+
 .. code-block:: js
 
   i18n`You have ${n} coins.`
 
 - *i18n.parts*: Interpolate i18nized values with arbitrary objects.
   Useful for example to include HTML elements.
+
 .. code-block:: js
 
   i18n.parts`Visit ${link} to get more coins.`
diff --git a/example-essay-store.rst b/example-essay-store.rst
index 102e54db..2a240f86 100644
--- a/example-essay-store.rst
+++ b/example-essay-store.rst
@@ -41,7 +41,9 @@ offer URL returns a HTML page that can either show a pay-form in case Taler is n
 in the user's browser or download the contract from the merchant.
 If the user has Taler installed and wants to pay, the wallet will POST the coins to a URL
 of the form:
+
   `https://blog.demo.taler.net/pay?uuid=${contract_hashcode}`
+
 The URL comes with the contract's hashcode because each contract is an entry in
 the merchant's state, so it can mark it as ``payed`` whenever it receives coins.
 
diff --git a/index.rst b/index.rst
index 15b06e0f..41e7bc05 100644
--- a/index.rst
+++ b/index.rst
@@ -53,8 +53,8 @@ It focuses on how to install, configure and run the required software.
 
   global_licensing
   configuration-basics
-  impl-exchange
-  impl-merchant
+  operate-exchange
+  operate-merchant
   versioning
 
 ------------------------
diff --git a/integration-bank.rst b/integration-bank.rst
index b8e24937..1dc2ec8d 100644
--- a/integration-bank.rst
+++ b/integration-bank.rst
@@ -26,11 +26,11 @@ As a result of the reserve creation request, the following steps will happen in
  2. Upon confirmation, the wallet fetches the desired amount from the user-filled form and
     prompts the user for the *exchange base URL*. Then ask the user to confirm creating the
     reserve.
- 2. The wallet will create a key pair for the reserve.
- 3. The wallet will request the CAPTCHA page to the bank. In that request's parameters it
+ 3. The wallet will create a key pair for the reserve.
+ 4. The wallet will request the CAPTCHA page to the bank. In that request's parameters it
     communicates the desired amount, the reserve's public key and the exchange base URL to the
     bank
- 4. Upon successful resolution of the CAPTCHA by the user, the bank initiates the reserve
+ 5. Upon successful resolution of the CAPTCHA by the user, the bank initiates the reserve
     creation according to the gotten parameters. Together with `200 OK` status code sent back
     to the wallet, it gets also a `ReserveCreated`_ object.
 
diff --git a/impl-exchange.rst b/operate-exchange.rst
index ce2cb4d7..b276d06d 100644
--- a/impl-exchange.rst
+++ b/operate-exchange.rst
@@ -139,7 +139,7 @@ Sections specifying denomination (coin) information start with "coin\_".  By con
 Keys duration
 -----------------------
 
-Both `signkeys` and `denom keys` have a :ref:`starting date <keys>` (see :ref:`how <keys-duration>` this date is calculated).
+Both `signkeys` and `denom keys` have a :ref:`starting date <keys-duration>`.
 The option `lookahead_provide`, under section `[exchange_keys]`, is such that only keys whose starting date is
 younger than `lookahead_provide` will be issued by the exchange.
 
diff --git a/impl-merchant.rst b/operate-merchant.rst
index 45c83baf..572c7d6d 100644
--- a/impl-merchant.rst
+++ b/operate-merchant.rst
@@ -59,8 +59,7 @@ it is mandatory to supply the connection string (namely, the database name). Thi
 possible in two ways:
 
 * via an environment variable: `TALER_MERCHANTDB_POSTGRES_CONFIG`.
-* via configuration option `config`, under section `[merchantdb-BACKEND]`. For example,
-the demo merchant is configured as follows:
+* via configuration option `config`, under section `[merchantdb-BACKEND]`. For example, the demo merchant is configured as follows:
 
 .. code-block:: text