Propose fix some typos and rm trailing whitespace

_overviews/FAQ/yield.md

@@ -116,7 +116,7 @@ returning a list of odds -- since `found` is `false`. Only then `foreach` is
 executed, but, by this time, changing `found` is meaningless, as `filter` has
 already executed.
 
-In the case of `Stream`, the condition is not immediatelly applied. Instead, as
+In the case of `Stream`, the condition is not immediately applied. Instead, as
 each element is requested by `foreach`, `filter` tests the condition, which
 enables `foreach` to influence it through `found`. Just to make it clear, here
 is the equivalent for-comprehension code:

_overviews/core/futures.md

@@ -56,7 +56,7 @@ Or with the more idiomatic:
 Both code snippets delegate the execution of `fatMatrix.inverse()` to an `ExecutionContext` and embody the result of the computation in `inverseFuture`.
 
 
-## Execution Context   
+## Execution Context
 
 Future and Promises revolve around [`ExecutionContext`s](http://www.scala-lang.org/api/current/index.html#scala.concurrent.ExecutionContext), responsible for executing computations.
 
@@ -144,7 +144,7 @@ To give you an idea, the following code will use 32000 threads:
     for( i <- 1 to 32000 ) {
       Future {
         blocking {
-          Thread.sleep(999999)		
+          Thread.sleep(999999)
         }
       }
     }
@@ -155,7 +155,7 @@ If you need to wrap long lasting blocking operations we recommend using a dedica
 
 ### Adapting a Java Executor
 
-Using the `ExecutionContext.fromExecutor` method you can wrap a Java `Executor` into an `ExecutionContext`.  
+Using the `ExecutionContext.fromExecutor` method you can wrap a Java `Executor` into an `ExecutionContext`.
 For instance:
 
     ExecutionContext.fromExecutor(new ThreadPoolExecutor( /* your configuration */ ))
@@ -333,7 +333,7 @@ a `List[String]`-- a list of recent textual posts:
 
     f onComplete {
       case Success(posts) => for (post <- posts) println(post)
-      case Failure(t) => println("An error has occured: " + t.getMessage)
+      case Failure(t) => println("An error has occurred: " + t.getMessage)
     }
 
 The `onComplete` method is general in the sense that it allows the
@@ -356,7 +356,7 @@ To handle failed results, the `onFailure` callback is used:
     }
 
     f onFailure {
-      case t => println("An error has occured: " + t.getMessage)
+      case t => println("An error has occurred: " + t.getMessage)
     }
 
     f onSuccess {

_overviews/plugins/index.md

@@ -5,7 +5,7 @@ title: Scala Compiler Plugins
 discourse: true
 ---
 
-**Lex Spoon (2008)**  
+**Lex Spoon (2008)**
 **Seth Tisue (2018)**
 
 ## Introduction
@@ -158,7 +158,7 @@ aspects of note.
 The `runsAfter` method gives the plugin author control over when the
 phase is executed. As seen above, it is expected to return a list of
 phase names. This makes it possible to specify multiple phase names to
-preceed the plugin. It is also possible, but optional, to specify a
+precede the plugin. It is also possible, but optional, to specify a
 `runsBefore` constraint of phase names that this phase should
 precede. And it is also possible, but again optional, to specify a
 `runsRightAfter` constraint to run immediately after a specific

_overviews/quasiquotes/unlifting.md

@@ -19,7 +19,7 @@ Unlifting is the reverse operation to [lifting](lifting.html): it takes a tree a
       def unapply(tree: Tree): Option[T]
     }
 
-Due to the fact that the tree may not be a represention of our data type, the return type of unapply is `Option[T]` rather than just `T`. This signature makes it easy to use `Unliftable` instances as extractors.
+Due to the fact that the tree may not be a representation of our data type, the return type of unapply is `Option[T]` rather than just `T`. This signature makes it easy to use `Unliftable` instances as extractors.
 
 Whenever an implicit instance of `Unliftable` is available for a given data type you can use it for pattern matching with the help of an ascription syntax:
 

_sips/sips/2016-01-11-static-members.md

@@ -148,7 +148,7 @@ It also does not address the question of `@static` members in inner objects and
 
 ## Initialization order discussion ##
 In general, emission of static fields could affect the initialization order and change semantics.
-This SIP solves this by enforcing (rule `2`) that `@static` fields and expressions preceed non-static fields.
+This SIP solves this by enforcing (rule `2`) that `@static` fields and expressions precede non-static fields.
 This means that no code precedes the `@static` field initialization which makes it hard to observe the difference between if the field is initialized statically or not,
 since fields are initialized in the order `as written`, similar to how normal fields are initialized.