Emphasis with underscore

commands/append.md

@@ -17,7 +17,7 @@ string, so `APPEND` will be similar to `SET` in this special case.
 ## Pattern: Time series
 
 the `APPEND` command can be used to create a very compact representation of a
-list of fixed-size samples, usually referred as *time series*. Every time a new
+list of fixed-size samples, usually referred as _time series_. Every time a new
 sample arrives we can store it using the command
 
     APPEND timeseries "fixed-size sample"

commands/bgrewriteaof.md

@@ -9,7 +9,7 @@ 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
+  _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.

commands/bitcount.md

@@ -2,7 +2,7 @@ Count the number of set bits (population counting) in a string.
 
 By default all the bytes contained in the string are examined. It is possible
 to specify the counting operation only in an interval passing the additional
-arguments *start* and *end*.
+arguments _start_ and _end_.
 
 Like for the `GETRANGE` command start and end can contain negative values in
 order to index bytes starting from the end of the string, where -1 is the last
@@ -59,6 +59,6 @@ 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*
+* 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,15 +4,15 @@ 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.
 
-The result of the operation is always stored at *destkey*.
+The result of the operation is always stored at _destkey_.
 
 ## Handling of strings with different lengths
 

commands/eval.md

@@ -212,7 +212,7 @@ means that if an `EVAL` is performed against a Redis instance all the subsequent
 `EVALSHA` calls will succeed.
 
 The only way to flush the script cache is by explicitly calling the SCRIPT FLUSH
-command, that will *completely flush* the scripts cache removing all the scripts
+command, that will _completely flush_ the scripts cache removing all the scripts
 executed so far. This is usually needed only when the instance is going to be
 instantiated for another customer or application in a cloud environment.
 
@@ -240,13 +240,13 @@ subsystem. SCRIPT currently accepts three different commands:
   can be reassigned to a different user. It is also useful for testing client
   libraries implementations of the scripting feature.
 
-* SCRIPT EXISTS *sha1* *sha2*... *shaN*. Given a list of SHA1 digests as
+* SCRIPT EXISTS _sha1_ _sha2_... _shaN_. Given a list of SHA1 digests as
   arguments this command returns an array of 1 or 0, where 1 means the specific
   SHA1 is recognized as a script already present in the scripting cache, while
   0 means that a script with this SHA1 was never seen before (or at least never
   seen after the latest SCRIPT FLUSH command).
 
-* SCRIPT LOAD *script*. This command registers the specified script in the
+* SCRIPT LOAD _script_. This command registers the specified script in the
   Redis script cache. The command is useful in all the contexts where we want
   to make sure that `EVALSHA` will not fail (for instance during a pipeline or
   MULTI/EXEC operation), without the need to actually execute the script.
@@ -274,7 +274,7 @@ scripts).
 The only drawback with this approach is that scripts are required to have the
 following property:
 
-* The script always evaluates the same Redis *write* commands with the same
+* The script always evaluates the same Redis _write_ commands with the same
   arguments given the same input data set. Operations performed by the script
   cannot depend on any hidden (non explicit) information or state that may
   change as script execution proceeds or between different executions of the
@@ -290,15 +290,15 @@ In order to enforce this behavior in scripts Redis does the following:
   state.
 
 * Redis will block the script with an error if a script will call a Redis
-  command able to alter the data set **after** a Redis *random* command like
+  command able to alter the data set **after** a Redis _random_ command like
   `RANDOMKEY`, `SRANDMEMBER`, `TIME`. This means that if a script is read only
   and does not modify the data set it is free to call those commands. Note that
-  a *random command* does not necessarily identifies a command that uses random
+  a _random command_ does not necessarily identifies a command that uses random
   numbers: any non deterministic command is considered a random command (the
   best example in this regard is the `TIME` command).
 
 * Redis commands that may return elements in random order, like `SMEMBERS`
-  (because Redis Sets are *unordered*) have a different behavior when called
+  (because Redis Sets are _unordered_) have a different behavior when called
   from Lua, and undergone a silent lexicographical sorting filter before
   returning data to Lua scripts. So `redis.call("smembers",KEYS[1])` will always
   return the Set elements in the same order, while the same command invoked from
@@ -394,7 +394,7 @@ returns with an error:
     redis 127.0.0.1:6379> eval 'a=10' 0
     (error) ERR Error running script (call to f_933044db579a2f8fd45d8065f04a8d0249383e57): user_script:1: Script attempted to create global variable 'a'
 
-Accessing a *non existing* global variable generates a similar error.
+Accessing a _non existing_ global variable generates a similar error.
 
 Using Lua debugging functionalities or other approaches like altering the meta
 table used to implement global protections, in order to circumvent globals
@@ -403,7 +403,7 @@ If the user messes with the Lua global state, the consistency of AOF and
 replication is not guaranteed: don't do it.
 
 Note for Lua newbies: in order to avoid using global variables in your scripts
-simply declare every variable you are going to use using the *local* keyword.
+simply declare every variable you are going to use using the _local_ keyword.
 
 ## Available libraries
 
@@ -417,7 +417,7 @@ The Redis Lua interpreter loads the following Lua libraries:
 * cjson lib.
 * cmsgpack lib.
 
-Every Redis instance is *guaranteed* to have all the above libraries so you can
+Every Redis instance is _guaranteed_ to have all the above libraries so you can
 be sure that the environment for your Redis scripts is always the same.
 
 The CJSON library allows to manipulate JSON data in a very fast way from Lua.

commands/expire.md

@@ -1,10 +1,10 @@
 Set a timeout on `key`. After the timeout has expired, the key will
 automatically be deleted. A key with an associated timeout is often said to be
-*volatile* in Redis terminology.
+_volatile_ in Redis terminology.
 
 The timeout is cleared only when the key is removed using the `DEL` command
 or overwritten using the `SET` or `GETSET` commands. This means that all the
-operations that conceptually *alter* the value stored at the key without
+operations that conceptually _alter_ the value stored at the key without
 replacing it with a new one will leave the timeout untouched. For instance,
 incrementing the value of a key with `INCR`, pushing a new value into a list
 with `LPUSH`, or altering the field value of a hash with `HSET` are all
@@ -24,9 +24,9 @@ inherit all the characteristics of `Key_B`.
 ## Refreshing expires
 
 It is possible to call `EXPIRE` using as argument a key that already has an
-existing expire set. In this case the time to live of a key is *updated* to the
+existing expire set. In this case the time to live of a key is _updated_ to the
 new value. There are many useful applications for this, an example is documented
-in the *Navigation session* pattern section below.
+in the _Navigation session_ pattern section below.
 
 ## Differences in Redis prior 2.1.3
 
@@ -54,9 +54,9 @@ now fixed.
 ## Pattern: Navigation session
 
 Imagine you have a web service and you are interested in the latest N pages
-*recently* visited by your users, such that each adiacent page view was not
+_recently_ visited by your users, such that each adiacent page view was not
 performed more than 60 seconds after the previous. Conceptually you may think at
-this set of page views as a *Navigation session* if your user, that may contain
+this set of page views as a _Navigation session_ if your user, that may contain
 interesting information about what kind of products he or she is looking for
 currently, so that you can recommend related products.
 

commands/getbit.md

@@ -1,13 +1,13 @@
-Returns the bit value at *offset* in the string value stored at *key*.
+Returns the bit value at _offset_ in the string value stored at _key_.
 
-When *offset* is beyond the string length, the string is assumed to be a
-contiguous space with 0 bits. When *key* does not exist it is assumed to be an
-empty string, so *offset* is always out of range and the value is also assumed
+When _offset_ is beyond the string length, the string is assumed to be a
+contiguous space with 0 bits. When _key_ does not exist it is assumed to be an
+empty string, so _offset_ is always out of range and the value is also assumed
 to be a contiguous space with 0 bits.
 
 @return
 
-@integer-reply: the bit value stored at *offset*.
+@integer-reply: the bit value stored at _offset_.
 
 @examples
 

commands/incr.md

@@ -54,7 +54,7 @@ public API.
 
 We provide two implementations of this pattern using `INCR`, where we assume
 that the problem to solve is limiting the number of API calls to a maximum of
-*ten requests per second per IP address*.
+_ten requests per second per IP address_.
 
 ## Pattern: Rate limiter 1
 

commands/migrate.md

@@ -28,11 +28,11 @@ the following two cases are possible:
 
 It is not possible for the key to get lost in the event of a timeout, but the
 client calling `MIGRATE`, in the event of a timeout error, should check if the
-key is *also* present in the target instance and act accordingly.
+key is _also_ present in the target instance and act accordingly.
 
 When any other error is returned (starting with `ERR`) `MIGRATE` guarantees that
 the key is still only present in the originating instance (unless a key with the
-same name was also *already* present on the target instance).
+same name was also _already_ present on the target instance).
 
 On success OK is returned.
 

commands/persist.md

@@ -1,5 +1,5 @@
-Remove the existing timeout on `key`, turning the key from *volatile* (a key
-with an expire set) to *persistent* (a key that will never expire as no timeout
+Remove the existing timeout on `key`, turning the key from _volatile_ (a key
+with an expire set) to _persistent_ (a key that will never expire as no timeout
 is associated).
 
 @return

commands/rpoplpush.md

@@ -33,16 +33,16 @@ pushing values into a list in the producer side, and waiting for this values
 in the consumer side using `RPOP` (using polling), or `BRPOP` if the client is
 better served by a blocking operation.
 
-However in this context the obtained queue is not *reliable* as messages can
+However in this context the obtained queue is not _reliable_ as messages can
 be lost, for example in the case there is a network problem or if the consumer
 crashes just after the message is received but it is still to process.
 
 `RPOPLPUSH` (or `BRPOPLPUSH` for the blocking variant) offers a way to avoid
 this problem: the consumer fetches the message and at the same time pushes it
-into a *processing* list. It will use the `LREM` command in order to remove the
-message from the *processing* list once the message has been processed.
+into a _processing_ list. It will use the `LREM` command in order to remove the
+message from the _processing_ list once the message has been processed.
 
-An additional client may monitor the *processing* list for items that remain
+An additional client may monitor the _processing_ list for items that remain
 there for too much time, and will push those timed out items into the queue
 again if needed.
 

commands/save.md

@@ -1,5 +1,5 @@
 The `SAVE` commands performs a **synchronous** save of the dataset producing a
-*point in time* snapshot of all the data inside the Redis instance, in the form
+_point in time_ snapshot of all the data inside the Redis instance, in the form
 of an RDB file.
 
 You almost never what to call `SAVE` in production environments where it will

commands/setbit.md

@@ -1,24 +1,24 @@
-Sets or clears the bit at *offset* in the string value stored at *key*.
+Sets or clears the bit at _offset_ in the string value stored at _key_.
 
-The bit is either set or cleared depending on *value*, which can be either 0 or
-1. When *key* does not exist, a new string value is created. The string is grown
-to make sure it can hold a bit at *offset*. The *offset* argument is required
+The bit is either set or cleared depending on _value_, which can be either 0 or
+1. When _key_ does not exist, a new string value is created. The string is grown
+to make sure it can hold a bit at _offset_. The _offset_ argument is required
 to be greater than or equal to 0, and smaller than 2^32 (this limits bitmaps to
-512MB). When the string at *key* is grown, added bits are set to 0.
+512MB). When the string at _key_ is grown, added bits are set to 0.
 
-**Warning**: When setting the last possible bit (*offset* equal to 2^32 -1) and
-the string value stored at *key* does not yet hold a string value, or holds
+**Warning**: When setting the last possible bit (_offset_ equal to 2^32 -1) and
+the string value stored at _key_ does not yet hold a string value, or holds
 a small string value, Redis needs to allocate all intermediate memory which
 can block the server for some time. On a 2010 MacBook Pro, setting bit number
 2^32 -1 (512MB allocation) takes ~300ms, setting bit number 2^30 -1 (128MB
 allocation) takes ~80ms, setting bit number 2^28 -1 (32MB allocation) takes
 ~30ms and setting bit number 2^26 -1 (8MB allocation) takes ~8ms. Note that once
-this first allocation is done, subsequent calls to `SETBIT` for the same *key*
+this first allocation is done, subsequent calls to `SETBIT` for the same _key_
 will not have the allocation overhead.
 
 @return
 
-@integer-reply: the original bit value stored at *offset*.
+@integer-reply: the original bit value stored at _offset_.
 
 @examples
 

commands/setrange.md

@@ -1,22 +1,22 @@
-Overwrites part of the string stored at *key*, starting at the specified offset,
-for the entire length of *value*. If the offset is larger than the current
-length of the string at *key*, the string is padded with zero-bytes to make
-*offset* fit. Non-existing keys are considered as empty strings, so this command
-will make sure it holds a string large enough to be able to set *value* at
-*offset*.
+Overwrites part of the string stored at _key_, starting at the specified offset,
+for the entire length of _value_. If the offset is larger than the current
+length of the string at _key_, the string is padded with zero-bytes to make
+_offset_ fit. Non-existing keys are considered as empty strings, so this command
+will make sure it holds a string large enough to be able to set _value_ at
+_offset_.
 
 Note that the maximum offset that you can set is 2^29 -1 (536870911), as Redis
 Strings are limited to 512 megabytes. If you need to grow beyond this size, you
 can use multiple keys.
 
 **Warning**: When setting the last possible byte and the string value stored at
-*key* does not yet hold a string value, or holds a small string value, Redis
+_key_ does not yet hold a string value, or holds a small string value, Redis
 needs to allocate all intermediate memory which can block the server for some
 time. On a 2010 MacBook Pro, setting byte number 536870911 (512MB allocation)
 takes ~300ms, setting byte number 134217728 (128MB allocation) takes ~80ms,
 setting bit number 33554432 (32MB allocation) takes ~30ms and setting bit number
 8388608 (8MB allocation) takes ~8ms. Note that once this first allocation is
-done, subsequent calls to `SETRANGE` for the same *key* will not have the
+done, subsequent calls to `SETRANGE` for the same _key_ will not have the
 allocation overhead.
 
 ## Patterns

commands/slowlog.md

@@ -8,10 +8,10 @@ with the client, sending the reply and so forth, but just the time needed to
 actually execute the command (this is the only stage of command execution where
 the thread is blocked and can not serve other requests in the meantime).
 
-You can configure the slow log with two parameters: *slowlog-log-slower-than*
+You can configure the slow log with two parameters: _slowlog-log-slower-than_
 tells Redis what is the execution time, in microseconds, to exceed in order for
 the command to get logged. Note that a negative number disables the slow log,
-while a value of zero forces the logging of every command. *slowlog-max-len*
+while a value of zero forces the logging of every command. _slowlog-max-len_
 is the length of the slow log. The minimum value is zero. When a new command
 is logged and the slow log is already at its maximum length, the oldest one is
 removed from the queue of logged commands in order to make space.
@@ -24,7 +24,7 @@ running using the `CONFIG GET` and `CONFIG SET` commands.
 The slow log is accumulated in memory, so no file is written with information
 about the slow command executions. This makes the slow log remarkably fast at
 the point that you can enable the logging of all the commands (setting the
-*slowlog-log-slower-than* config parameter to zero) with minor performance hit.
+_slowlog-log-slower-than_ config parameter to zero) with minor performance hit.
 
 To read the slow log the **SLOWLOG GET** command is used, that returns every
 entry in the slow log. It is possible to return only the N most recent entries

commands/zrangebyscore.md

@@ -7,7 +7,7 @@ follows from a property of the sorted set implementation in Redis and does not
 involve further computation).
 
 The optional `LIMIT` argument can be used to only get a range of the matching
-elements (similar to *SELECT LIMIT offset, count* in SQL). Keep in mind that if
+elements (similar to _SELECT LIMIT offset, count_ in SQL). Keep in mind that if
 `offset` is large, the sorted set needs to be traversed for `offset` elements
 before getting to the elements to return, which can add up to O(N) time
 complexity.

remarkdown.rb

@@ -102,7 +102,7 @@ def format_inline_node(node)
     else
       case node.name
       when "em"
-        "*" + format_inline_node(node.child) + "*"
+        "_" + format_inline_node(node.child) + "_"
       when "strong"
         "**" + format_inline_node(node.child) + "**"
       when "code"