Clean up language in the other section.

Author: michaeltwofish

doc/en/other/timeouts.md

@@ -1,26 +1,26 @@
 ### `setTimeout` and `setInterval`
 
 Since JavaScript is asynchronous, it is possible to schedule the execution of a 
-function by using the `setTimeout` and `setInterval` functions.
+function using the `setTimeout` and `setInterval` functions.
 
 > **Note:** Timeouts are **not** part of the ECMAScript Standard. They are
 > implemented as part of the [DOM][1].
 
     function foo() {}
     var id = setTimeout(foo, 1000); // returns a Number > 0
 
-When `setTimeout` gets called, it will return the ID of the timeout and schedule
-`foo` to run in **approximately** one thousand milliseconds in the future. 
-`foo` will then get executed exactly **once**.
+When `setTimeout` is called, it returns the ID of the timeout and schedule
+`foo` to run **approximately** one thousand milliseconds in the future. 
+`foo` will then be executed **once**.
 
-Depending on the timer resolution of the JavaScript engine that is running the 
-code, as well as the fact that JavaScript is single threaded and other code that 
-gets executed might block the thread, it is by **no means** a safe bet that one 
-will get the exact delay that was specified in the `setTimeout` call.
+Depending on the timer resolution of the JavaScript engine running the code, as
+well as the fact that JavaScript is single threaded and other code that gets
+executed might block the thread, it is by **no means** a safe bet that one will
+get the exact delay specified in the `setTimeout` call.
 
 The function that was passed as the first parameter will get called by the
 *global object*, which means that [`this`](#function.this) inside the called function 
-refers to that very object.
+refers to the global object.
 
     function Foo() {
         this.value = 42;
@@ -34,7 +34,7 @@ refers to that very object.
 
 
 > **Note:** As `setTimeout` takes a **function object** as its first parameter, an
-> often made mistake is to use `setTimeout(foo(), 1000)`, which will use the 
+> common mistake is to use `setTimeout(foo(), 1000)`, which will use the 
 > **return value** of the call `foo` and **not** `foo`. This is, most of the time, 
 > a silent error, since when the function returns `undefined` `setTimeout` will 
 > **not** raise any error.
@@ -72,29 +72,31 @@ the function itself.
     foo();
 
 Not only does this encapsulate the `setTimeout` call, but it also prevents the
-stacking of calls and it gives additional control. `foo` itself can now decide 
+stacking of calls and gives additional control. `foo` itself can now decide 
 whether it wants to run again or not.
 
 ### Manually Clearing Timeouts
 
 Clearing timeouts and intervals works by passing the respective ID to
-`clearTimeout` or `clearInterval`, depending which `set` function was used in
-the first place.
+`clearTimeout` or `clearInterval`, depending on which `set` function was used
+in the first place.
 
     var id = setTimeout(foo, 1000);
     clearTimeout(id);
 
-### Clearing all timeouts
+### Clearing All Timeouts
 
-Because there is no built-in method for clearing all timeouts and/or intervals, 
+As there is no built-in method for clearing all timeouts and/or intervals, 
 it is necessary to use brute force in order to achieve this functionality.
 
     // clear "all" timeouts
     for(var i = 1; i < 1000; i++) {
         clearTimeout(i);
     }
 
-But there might still be timeouts that are unaffected by this arbitrary number. Another way of doing this is to consider that the ID given to a timeout is incremented by one everytime you call `setTimeout`.
+But there might still be timeouts that are unaffected by this arbitrary number.
+Another way of doing this is to consider that the ID given to a timeout is
+incremented by one every time you call `setTimeout`.
 
     // clear "all" timeouts
     var biggestTimeoutId = window.setTimeout(function(){}, 1),
@@ -103,17 +105,19 @@ But there might still be timeouts that are unaffected by this arbitrary number.
         clearTimeout(i);
     }
 
-But even though this works on all main browsers nowadays, it isn't specified that the IDs should be ordered that way and it may change. Therefore, it is instead recommended to keep track of all the timeout IDs, so
-they can be cleared specifically.
+Even though this works on all major browsers today, it isn't specified that
+the IDs should be ordered that way and it may change. Therefore, it is instead
+recommended to keep track of all the timeout IDs, so they can be cleared
+specifically.
 
-### Hidden use of `eval`
+### Hidden Use of `eval`
 
 `setTimeout` and `setInterval` can also take a string as their first parameter.
 This feature should **never** be used because it internally makes use of `eval`.
 
 > **Note:** Since the timeout functions are **not** specified by the ECMAScript
 > standard, the exact workings when a string is passed to them might differ in
-> various JavaScript implementations. For example, Microsoft's JScript makes use of
+> various JavaScript implementations. For example, Microsoft's JScript uses
 > the `Function` constructor in place of `eval`.
 
     function foo() {
@@ -129,10 +133,10 @@ This feature should **never** be used because it internally makes use of `eval`.
     bar();
 
 Since `eval` is not getting called [directly](#core.eval) in this case, the string 
-passed to `setTimeout` will get executed in the *global scope*; thus, it will 
+passed to `setTimeout` will be executed in the *global scope*; thus, it will 
 not use the local variable `foo` from the scope of `bar`.
 
-It is further recommended to **not** use a string for passing arguments to the
+It is further recommended to **not** use a string to pass arguments to the
 function that will get called by either of the timeout functions. 
 
     function foo(a, b, c) {}
@@ -151,7 +155,7 @@ function that will get called by either of the timeout functions.
 
 ### In Conclusion
 
-**Never** should a string be used as the parameter of `setTimeout` or 
+A string should **never** be used as the parameter of `setTimeout` or 
 `setInterval`. It is a clear sign of **really** bad code, when arguments need 
 to be supplied to the function that gets called. An *anonymous function* should
 be passed that then takes care of the actual call.