Copy edits for typos/misspellings

commands/command.md

@@ -99,7 +99,7 @@ Command flags is @array-reply containing one or more status replies:
 
 Some Redis commands have no predetermined key locations.  For those commands,
 flag `movablekeys` is added to the command flags @array-reply.  Your Redis
-Cluster client needs to parse commands marked `movabkeleys` to locate all relevant key positions.
+Cluster client needs to parse commands marked `movablekeys` to locate all relevant key positions.
 
 Complete list of commands currently requiring key location parsing:
 

topics/ARM.md

@@ -21,7 +21,7 @@ reasons:
 ## Redis /proc/cpu/alignment requirements
 
 Linux on ARM allows to trap unaligned accesses and fix them inside the kernel
-in order to continue the exeuction of the offending program instead of
+in order to continue the execution of the offending program instead of
 generating a SIGBUS. Redis 4.0 and greater are fixed in order to avoid any kind
 of unaligned access, so there is no need to have a specific value for this
 kernel configuration. Even when kernel alignment fixing is disabled Redis should
@@ -35,13 +35,13 @@ run as expected.
 There is nothing special in the process. The only difference is that by
 default, Redis uses the libc allocator instead of defaulting to Jemalloc
 as it does in other Linux based environments. This is because we believe
-that for the small use cases inside embeddeed devices, memory fragmentation
+that for the small use cases inside embedded devices, memory fragmentation
 is unlikely to be a problem. Moreover Jemalloc on ARM may not be as tested
 as the libc allocator.
 
 ## Performance
 
-Performance testing of Redis was performend in the Raspberry Pi 3 and in the
+Performance testing of Redis was performed in the Raspberry Pi 3 and in the
 original model B Pi. The difference between the two Pis in terms of
 delivered performance is quite big. The benchmarks were performed via the
 loopback interface, since most use cases will probably use Redis from within

topics/indexes.md

@@ -644,7 +644,7 @@ What we do is to start with the left bottom corner of our search box,
 which is 50,100, and find the first range by substituting the last 6 bits
 in each number with 0. Then we do the same with the right top corner.
 
-With two trivial nested for loops where we increment only the significative
+With two trivial nested for loops where we increment only the significant
 bits, we can find all the squares between these two. For each square we
 convert the two numbers into our interleaved representation, and create
 the range using the converted representation as our start, and the same
@@ -687,7 +687,7 @@ Turning this into code is simple. Here is a Ruby example:
 
 While non immediately trivial this is a very useful indexing strategy that
 in the future may be implemented in Redis in a native way.
-For now, the good thing is that the complexity may be easily encapsualted
+For now, the good thing is that the complexity may be easily encapsulated
 inside a library that can be used in order to perform indexing and queries.
 One example of such library is [Redimension](https://github.com/antirez/redimension), a proof of concept Ruby library which indexes N-dimensional data inside Redis using the technique described here.
 

topics/rediscli.md

@@ -679,7 +679,7 @@ name is simply `--slave`. This is how it works:
     "SELECT","0"
     "set","foo","bar"
     "PING"
-    "incr","myconuter"
+    "incr","mycounter"
 
 The command begins by discarding the RDB file of the first synchronization
 and then logs each command received as in CSV format.

topics/replication.md

@@ -149,7 +149,7 @@ use case for storing ephemeral data in writable slaves.
 For example computing slow set or zset operations and storing them into local
 keys is an use case for writable slaves that was observed multiple times.
 
-However note that **writable slaves before version 4.0 were uncapable of expiring keys with a time to live set**. This means that if you use `EXPIRE` or other commands that set a maximum TTL for a key, the key will leak, and while you may no longer see it while accessing it with read commands, you will see it in the count of keys and it will still use memory. So in general mixing writable slaves (previous version 4.0) and keys with TTL is going to create issues.
+However note that **writable slaves before version 4.0 were incapable of expiring keys with a time to live set**. This means that if you use `EXPIRE` or other commands that set a maximum TTL for a key, the key will leak, and while you may no longer see it while accessing it with read commands, you will see it in the count of keys and it will still use memory. So in general mixing writable slaves (previous version 4.0) and keys with TTL is going to create issues.
 
 Redis 4.0 RC3 and greater totally resolve this problem and now writable
 slaves are able to evict keys with TTL as masters do, with the exceptions

topics/twitter-clone.md

@@ -265,7 +265,7 @@ This is the actual code:
         goback("Wrong username or password");
     $realpassword = $r->hget("user:$userid","password");
     if ($realpassword != $password)
-        goback("Wrong useranme or password");
+        goback("Wrong username or password");
 
     # Username / password OK, set the cookie and redirect to index.php
     $authsecret = $r->hget("user:$userid","auth");