Reformat command documentation

Rakefile

@@ -42,24 +42,17 @@ end
 
 namespace :format do
 
+  require "./remarkdown"
+
   def format(file)
     return unless File.exist?(file)
 
     STDOUT.print "formatting #{file}..."
     STDOUT.flush
 
-    matcher = /^(?:\A|\r?\n)((?:[a-zA-Z@].+?\r?\n)+)/m
-    body = File.read(file).gsub(matcher) do |match|
-      formatted = nil
-
-      IO.popen("par p0s0w80", "r+") do |io|
-        io.puts match
-        io.close_write
-        formatted = io.read
-      end
-
-      formatted
-    end
+    body = File.read(file)
+    body = ReMarkdown.new(body).to_s
+    body = body.gsub(/^\s+$/, "")
 
     File.open(file, "w") do |f|
       f.print body

commands/append.md

@@ -25,7 +25,10 @@ sample arrives we can store it using the command
 Accessing individual elements in the time series is not hard:
 
 * `STRLEN` can be used in order to obtain the number of samples.
-* `GETRANGE` allows for random access of elements. If our time series have an associated time information we can easily implement a binary search to get range combining `GETRANGE` with the Lua scripting engine available in Redis 2.6.
+* `GETRANGE` allows for random access of elements. If our time series have an
+  associated time information we can easily implement a binary search to get
+  range combining `GETRANGE` with the Lua scripting engine available in Redis
+  2.6.
 * `SETRANGE` can be used to overwrite an existing time serie.
 
 The limitations of this pattern is that we are forced into an append-only mode

commands/auth.md

@@ -7,10 +7,9 @@ with the `OK` status code and starts accepting commands. Otherwise, an error is
 returned and the clients needs to try a new password.
 
 **Note**: because of the high performance nature of Redis, it is possible to try
-a lot of passwords in parallel in very short time, so make sure to generate
-a strong and very long password so that this attack is infeasible.
+a lot of passwords in parallel in very short time, so make sure to generate a
+strong and very long password so that this attack is infeasible.
 
 @return
 
 @status-reply
-

commands/bgrewriteaof.md

@@ -1,23 +1,27 @@
-Instruct Redis to start an [Append Only File][aof] rewrite process. The rewrite
-will create a small optimized version of the current Append Only File.
+Instruct Redis to start an [Append Only File][tpaof] rewrite process. The
+rewrite will create a small optimized version of the current Append Only File.
 
-[aof]: /topics/persistence#append-only-file
+[tpaof]: /topics/persistence#append-only-file
 
 If `BGREWRITEAOF` fails, no data gets lost as the old AOF will be untouched.
 
 The rewrite will be only triggered by Redis if there is not already a background
 process doing persistence. Specifically:
 
-* If a Redis child is creating a snapshot on disk, the AOF rewrite is *scheduled* but not started until the saving child producing the RDB file terminates. In this case the `BGREWRITEAOF` will still return an OK code, but with an appropriate message. You can check if an AOF rewrite is scheduled looking at the `INFO` command starting from Redis 2.6.
-* If an AOF rewrite is already in progress the command returns an error and no AOF rewrite will be scheduled for a later time.
+* If a Redis child is creating a snapshot on disk, the AOF rewrite is
+  *scheduled* but not started until the saving child producing the RDB file
+  terminates. In this case the `BGREWRITEAOF` will still return an OK code, but
+  with an appropriate message. You can check if an AOF rewrite is scheduled
+  looking at the `INFO` command starting from Redis 2.6.
+* If an AOF rewrite is already in progress the command returns an error and no
+  AOF rewrite will be scheduled for a later time.
 
 Since Redis 2.4 the AOF rewrite is automatically triggered by Redis, however the
 `BGREWRITEAOF` command can be used to trigger a rewrite at any time.
 
-Please refer to the [persistence documentation][persistence] for detailed
-information.
+Please refer to the [persistence documentation][tp] for detailed information.
 
-[persistence]: /topics/persistence
+[tp]: /topics/persistence
 
 @return
 

commands/bgsave.md

@@ -1,14 +1,11 @@
-
-
 Save the DB in background. The OK code is immediately returned. Redis forks,
-the parent continues to server the clients, the child saves the DB on disk then
-exit. A client my be able to check if the operation succeeded using the
+the parent continues to server the clients, the child saves the DB on disk
+then exit. A client my be able to check if the operation succeeded using the
 `LASTSAVE` command.
 
-Please refer to the [persistence documentation][persistence] for detailed
-information.
+Please refer to the [persistence documentation][tp] for detailed information.
 
-[persistence]: /topics/persistence
+[tp]: /topics/persistence
 
 @return
 

commands/bitcount.md

@@ -42,10 +42,11 @@ the bit corresponding to the current day.
 Later it will be trivial to know the number of single days the user visited the
 web site simply calling the `BITCOUNT` command against the bitmap.
 
-A similar pattern where user IDs are used instead of days is described in the
-article called "[Fast easy realtime metrics using Redis bitmaps][bitmaps]".
+A similar pattern where user IDs are used instead of days is described
+in the article called "[Fast easy realtime metrics using Redis
+bitmaps][hbgc212fermurb]".
 
-[bitmaps]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
+[hbgc212fermurb]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
 
 ## Performance considerations
 
@@ -56,5 +57,8 @@ Redis command like `GET` or `INCR`.
 
 When the bitmap is big, there are two alternatives:
 
-+ Taking a separated key that is incremented every time the bitmap is modified. This can be very efficient and atomic using a small Redis Lua script.
-+ Running the bitmap incrementally using the `BITCOUNT` *start* and *end* optional parameters, accumulating the results client-side, and optionally caching the result into a key.
+* Taking a separated key that is incremented every time the bitmap is modified.
+  This can be very efficient and atomic using a small Redis Lua script.
+* Running the bitmap incrementally using the `BITCOUNT` *start* and *end*
+  optional parameters, accumulating the results client-side, and optionally
+  caching the result into a key.

commands/bitop.md

@@ -4,10 +4,10 @@ store the result in the destination key.
 The `BITOP` command supports four bitwise operations: **AND**, **OR**, **XOR**
 and **NOT**, thus the valid forms to call the command are:
 
-+ BITOP AND *destkey srckey1 srckey2 srckey3 ... srckeyN*
-+ BITOP OR *destkey srckey1 srckey2 srckey3 ... srckeyN*
-+ BITOP XOR *destkey srckey1 srckey2 srckey3 ... srckeyN*
-+ BITOP NOT *destkey srckey*
+* BITOP AND *destkey srckey1 srckey2 srckey3 ... srckeyN*
+* BITOP OR *destkey srckey1 srckey2 srckey3 ... srckeyN*
+* BITOP XOR *destkey srckey1 srckey2 srckey3 ... srckeyN*
+* BITOP NOT *destkey srckey*
 
 As you can see **NOT** is special as it only takes an input key, because it
 performs inversion of bits so it only makes sense as an unary operator.
@@ -40,18 +40,19 @@ size of the longest input string.
 
 ## Pattern: real time metrics using bitmaps
 
-`BITOP` is a good complement to the pattern documented in the `BITCOUNT` command documentation. Different bitmaps can be combined in order to obtain a target
+`BITOP` is a good complement to the pattern documented in the `BITCOUNT` command
+documentation. Different bitmaps can be combined in order to obtain a target
 bitmap where to perform the population counting operation.
 
 See the article called "[Fast easy realtime metrics using Redis
-bitmaps][bitmaps]" for an interesting use cases.
+bitmaps][hbgc212fermurb]" for an interesting use cases.
 
-[bitmaps]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
+[hbgc212fermurb]: http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps
 
 ## Performance considerations
 
-`BITOP` is a potentially slow command as it runs in O(N) time.
-Care should be taken when running it against long input strings.
+`BITOP` is a potentially slow command as it runs in O(N) time. Care should be
+taken when running it against long input strings.
 
 For real time metrics and statistics involving large inputs a good approach is
 to use a slave (with read-only option disabled) where to perform the bit-wise

commands/blpop.md

@@ -1,4 +1,4 @@
-`BLPOP` is a blocking list pop primitive.  It is the blocking version of `LPOP`
+`BLPOP` is a blocking list pop primitive. It is the blocking version of `LPOP`
 because it blocks the connection when there are no elements to pop from any of
 the given lists. An element is popped from the head of the first list that is
 non-empty, with the given keys being checked in the order that they are given.
@@ -10,8 +10,8 @@ non-empty list, an element is popped from the head of the list and returned to
 the caller together with the `key` it was popped from.
 
 Keys are checked in the order that they are given. Let's say that the key
-`list1` doesn't exist and `list2` and `list3` hold non-empty lists. Consider
-the following command:
+`list1` doesn't exist and `list2` and `list3` hold non-empty lists. Consider the
+following command:
 
     BLPOP list1 list2 list3 0
 
@@ -37,30 +37,31 @@ be used to block indefinitely.
 
 ## Multiple clients blocking for the same keys
 
-Multiple clients can block for the same key. They are put into a queue, so
-the first to be served will be the one that started to wait earlier, in a
-first-`!BLPOP` first-served fashion.
+Multiple clients can block for the same key. They are put into a queue, so the
+first to be served will be the one that started to wait earlier, in a first-
+`!BLPOP` first-served fashion.
 
-## `!BLPOP` inside a `!MULTI`/`!EXEC` transaction
+## `!BLPOP` inside a `!MULTI` / `!EXEC` transaction
 
 `BLPOP` can be used with pipelining (sending multiple commands and reading the
-replies in batch), but it does not make sense to use `BLPOP` inside a
-`MULTI`/`EXEC` block. This would require blocking the entire server in order to
-execute the block atomically, which in turn does not allow other clients to
-perform a push operation.
+replies in batch), but it does not make sense to use `BLPOP` inside a `MULTI` /
+`EXEC` block. This would require blocking the entire server in order to execute
+the block atomically, which in turn does not allow other clients to perform a
+push operation.
 
-The behavior of `BLPOP` inside `MULTI`/`EXEC` when the list is empty is to
+The behavior of `BLPOP` inside `MULTI` / `EXEC` when the list is empty is to
 return a `nil` multi-bulk reply, which is the same thing that happens when
 the timeout is reached. If you like science fiction, think of time flowing at
-infinite speed inside a `MULTI`/`EXEC` block.
+infinite speed inside a `MULTI` / `EXEC` block.
 
 @return
 
 @multi-bulk-reply: specifically:
 
 * A `nil` multi-bulk when no element could be popped and the timeout expired.
-* A two-element multi-bulk with the first element being the name of the key where an element
-  was popped and the second element being the value of the popped element.
+* A two-element multi-bulk with the first element being the name of the key
+  where an element was popped and the second element being the value of the
+  popped element.
 
 @examples
 
@@ -96,5 +97,3 @@ While in the producer side we'll use simply:
     SADD key element
     LPUSH helper_key x
     EXEC
-
-

commands/brpop.md

@@ -1,21 +1,22 @@
-`BRPOP` is a blocking list pop primitive.  It is the blocking version of
-`RPOP` because it blocks the connection when there are no
-elements to pop from any of the given lists. An element is popped from the
-tail of the first list that is non-empty, with the given keys being checked
-in the order that they are given.
+`BRPOP` is a blocking list pop primitive. It is the blocking version of `RPOP`
+because it blocks the connection when there are no elements to pop from any of
+the given lists. An element is popped from the tail of the first list that is
+non-empty, with the given keys being checked in the order that they are given.
 
-See the [BLPOP documentation](/commands/blpop) for the exact semantics, since
-`BRPOP` is identical to `BLPOP` with the only difference
-being that it pops elements from the tail of a list instead of popping from the
-head.
+See the [BLPOP documentation][cb] for the exact semantics, since `BRPOP` is
+identical to `BLPOP` with the only difference being that it pops elements from
+the tail of a list instead of popping from the head.
+
+[cb]: /commands/blpop
 
 @return
 
 @multi-bulk-reply: specifically:
 
 * A `nil` multi-bulk when no element could be popped and the timeout expired.
-* A two-element multi-bulk with the first element being the name of the key where an element
-  was popped and the second element being the value of the popped element.
+* A two-element multi-bulk with the first element being the name of the key
+  where an element was popped and the second element being the value of the
+  popped element.
 
 @examples
 

commands/brpoplpush.md

@@ -1,14 +1,14 @@
-`BRPOPLPUSH` is the blocking variant of `RPOPLPUSH`.
-When `source` contains elements, this command behaves exactly like
-`RPOPLPUSH`. When `source` is empty, Redis will block
-the connection until another client pushes to it or until `timeout` is reached. A `timeout` of zero can be used to block indefinitely.
+`BRPOPLPUSH` is the blocking variant of `RPOPLPUSH`. When `source` contains
+elements, this command behaves exactly like `RPOPLPUSH`. When `source` is empty,
+Redis will block the connection until another client pushes to it or until
+`timeout` is reached. A `timeout` of zero can be used to block indefinitely.
 
 See `RPOPLPUSH` for more information.
 
 @return
 
-@bulk-reply: the element being popped from `source` and pushed to
-`destination`. If `timeout` is reached, a @nil-reply is returned.
+@bulk-reply: the element being popped from `source` and pushed to `destination`.
+If `timeout` is reached, a @nil-reply is returned.
 
 ## Pattern: Reliable queue
 

commands/config get.md

@@ -3,12 +3,12 @@ running Redis server. Not all the configuration parameters are supported in
 Redis 2.4, while Redis 2.6 can read the whole configuration of a server using
 this command.
 
-The symmetric command used to alter the configuration at run time is
-`CONFIG SET`.
+The symmetric command used to alter the configuration at run time is `CONFIG
+SET`.
 
 `CONFIG GET` takes a single argument, that is glob style pattern. All the
-configuration parameters matching this parameter are reported as a
-list of key-value pairs. Example:
+configuration parameters matching this parameter are reported as a list of
+key-value pairs. Example:
 
     redis> config get *max-*-entries*
     1) "hash-max-zipmap-entries"
@@ -22,13 +22,17 @@ You can obtain a list of all the supported configuration parameters typing
 `CONFIG GET *` in an open `redis-cli` prompt.
 
 All the supported parameters have the same meaning of the equivalent
-configuration parameter used in the [redis.conf][conf] file, with the following
-important differences:
+configuration parameter used in the [redis.conf][hgcarr22rc] file, with the
+following important differences:
 
-[conf]: http://github.com/antirez/redis/raw/2.2/redis.conf
+[hgcarr22rc]: http://github.com/antirez/redis/raw/2.2/redis.conf
 
-* Where bytes or other quantities are specified, it is not possible to use the `redis.conf` abbreviated form (10k 2gb ... and so forth), everything should be specified as a well formed 64 bit integer, in the base unit of the configuration directive.
-* The save parameter is a single string of space separated integers. Every pair of integers represent a seconds/modifications threshold.
+* Where bytes or other quantities are specified, it is not possible to use
+  the `redis.conf` abbreviated form (10k 2gb ... and so forth), everything
+  should be specified as a well formed 64 bit integer, in the base unit of the
+  configuration directive.
+* The save parameter is a single string of space separated integers. Every pair
+  of integers represent a seconds/modifications threshold.
 
 For instance what in `redis.conf` looks like:
 

commands/config set.md

@@ -11,13 +11,17 @@ by Redis that will start acting as specified starting from the next command
 executed.
 
 All the supported parameters have the same meaning of the equivalent
-configuration parameter used in the [redis.conf][conf] file, with the following
-important differences:
+configuration parameter used in the [redis.conf][hgcarr22rc] file, with the
+following important differences:
 
-[conf]: http://github.com/antirez/redis/raw/2.2/redis.conf
+[hgcarr22rc]: http://github.com/antirez/redis/raw/2.2/redis.conf
 
-* Where bytes or other quantities are specified, it is not possible to use the `redis.conf` abbreviated form (10k 2gb ... and so forth), everything should be specified as a well formed 64 bit integer, in the base unit of the configuration directive.
-* The save parameter is a single string of space separated integers. Every pair of integers represent a seconds/modifications threshold.
+* Where bytes or other quantities are specified, it is not possible to use
+  the `redis.conf` abbreviated form (10k 2gb ... and so forth), everything
+  should be specified as a well formed 64 bit integer, in the base unit of the
+  configuration directive.
+* The save parameter is a single string of space separated integers. Every pair
+  of integers represent a seconds/modifications threshold.
 
 For instance what in `redis.conf` looks like:
 
@@ -30,15 +34,15 @@ be set using `CONFIG SET` as "900 1 300 10".
 
 It is possible to switch persistence from RDB snapshotting to append only file
 (and the other way around) using the `CONFIG SET` command. For more information
-about how to do that please check [persistence page][persistence].
+about how to do that please check [persistence page][tp].
 
-[persistence]: /topics/persistence
+[tp]: /topics/persistence
 
 In general what you should know is that setting the `appendonly` parameter to
 `yes` will start a background process to save the initial append only file
 (obtained from the in memory data set), and will append all the subsequent
-commands on the append only file, thus obtaining exactly the same effect of
-a Redis server that started with AOF turned on since the start.
+commands on the append only file, thus obtaining exactly the same effect of a
+Redis server that started with AOF turned on since the start.
 
 You can have both the AOF enabled with RDB snapshotting if you want, the two
 options are not mutually exclusive.

commands/dbsize.md

@@ -1,5 +1,3 @@
-
-
 Return the number of keys in the currently selected database.
 
 @return

commands/debug object.md

@@ -1,4 +1,4 @@
-`DEBUG OBJECT` is a debugging command that should not be used by clients.
-Check the `OBJECT` command instead.
+`DEBUG OBJECT` is a debugging command that should not be used by clients. Check
+the `OBJECT` command instead.
 
 @status-reply