diff --git a/docs/faq.rst b/docs/faq.rst
index 94e006180..acd6d8599 100644
--- a/docs/faq.rst
+++ b/docs/faq.rst
@@ -67,14 +67,14 @@ adjust the level or algorithm).
 
 |project_name| offers a lot of different compression algorithms and
 levels. Which of them is the best for you pretty much depends on your
-use case, your data, your hardware - so you need to do an informed
+use case, your data, your hardware -- so you need to do an informed
 decision about whether you want to use compression, which algorithm
 and which level you want to use. This is why compression defaults to
 none.
 
 How can I specify the encryption passphrase programmatically?
 -------------------------------------------------------------
-      
+
 The encryption passphrase can be specified programmatically using the
 `BORG_PASSPHRASE` environment variable. This is convenient when setting up
 automated encrypted backups. Another option is to use
@@ -93,7 +93,7 @@ key file based encryption with a blank passphrase. See
 
 When backing up to remote encrypted repos, is encryption done locally?
 ----------------------------------------------------------------------
-     
+
 Yes, file and directory metadata and data is locally encrypted, before
 leaving the local machine. We do not mean the transport layer encryption
 by that, but the data/metadata itself. Transport layer encryption (e.g.
diff --git a/docs/internals.rst b/docs/internals.rst
index 468e38b74..c8008f654 100644
--- a/docs/internals.rst
+++ b/docs/internals.rst
@@ -207,7 +207,7 @@ The |project_name| chunker uses a rolling hash computed by the Buzhash_ algorith
 It triggers (chunks) when the last HASH_MASK_BITS bits of the hash are zero,
 producing chunks of 2^HASH_MASK_BITS Bytes on average.
 
-create --chunker-params CHUNK_MIN_EXP,CHUNK_MAX_EXP,HASH_MASK_BITS,HASH_WINDOW_SIZE
+``borg create --chunker-params CHUNK_MIN_EXP,CHUNK_MAX_EXP,HASH_MASK_BITS,HASH_WINDOW_SIZE``
 can be used to tune the chunker parameters, the default is:
 
 - CHUNK_MIN_EXP = 10 (minimum chunk size = 2^10 B = 1 kiB)
@@ -311,28 +311,27 @@ more chunks than estimated above, because 1 file is at least 1 chunk).
 
 If a remote repository is used the repo index will be allocated on the remote side.
 
-E.g. backing up a total count of 1Mi files with a total size of 1TiB.
+E.g. backing up a total count of 1MiB files with a total size of 1TiB.
 
-a) with create --chunker-params 10,23,16,4095 (default):
+a) with create ``--chunker-params 10,23,16,4095`` (default):
 
   mem_usage  =  2.8GiB
 
-b) with create --chunker-params 10,23,20,4095 (custom):
+b) with create ``--chunker-params 10,23,20,4095`` (custom):
 
   mem_usage  =  0.4GiB
 
-Note: there is also the --no-files-cache option to switch off the files cache.
-You'll save some memory, but it will need to read / chunk all the files then as
-it can not skip unmodified files then.
-
+.. note:: There is also the ``--no-files-cache`` option to switch off the files cache.
+   You'll save some memory, but it will need to read / chunk all the files as
+   it can not skip unmodified files then.
 
 Encryption
 ----------
 
-AES_ is used in CTR mode (so no need for padding). A 64bit initialization
+AES_-256 is used in CTR mode (so no need for padding). A 64bit initialization
 vector is used, a `HMAC-SHA256`_ is computed on the encrypted chunk with a
 random 64bit nonce and both are stored in the chunk.
-The header of each chunk is : ``TYPE(1)`` + ``HMAC(32)`` + ``NONCE(8)`` + ``CIPHERTEXT``.
+The header of each chunk is: ``TYPE(1)`` + ``HMAC(32)`` + ``NONCE(8)`` + ``CIPHERTEXT``.
 Encryption and HMAC use two different keys.
 
 In AES CTR mode you can think of the IV as the start value for the counter.