spec: fix latex formatting all over the place

Two things worth mentioning:

 - `\em` and `emph` are not supported by MathJax,
 - and things like `\mathcal{C}_0` require escaping the `_`,
   otherwise markdown sees it as the beginning of  `_some string_`.
   It doesn't happen without the closing bracket in front, e.g. in `b_0`.

9 files changed, 104 insertions, 101 deletions

diff --git a/spec/01-lexical-syntax.md b/spec/01-lexical-syntax.md
index 6c8712cda2..ef1f2bf053 100644
--- a/spec/01-lexical-syntax.md
+++ b/spec/01-lexical-syntax.md
@@ -429,7 +429,7 @@ by an [escape sequence](#escape-sequences).
 
 Note that `'\u000A'` is _not_ a valid character literal because
 Unicode conversion is done before literal parsing and the Unicode
-character \\u000A (line feed) is not a printable
+character `\u000A` (line feed) is not a printable
 character. One can use instead the escape sequence `'\n'` or
 the octal escape `'\12'` ([see here](#escape-sequences)).
 
@@ -528,7 +528,7 @@ The following escape sequences are recognized in character and string literals.
 
 
 A character with Unicode between 0 and 255 may also be represented by
-an octal escape, i.e. a backslash ‘\’ followed by a
+an octal escape, i.e. a backslash `'\'` followed by a
 sequence of up to three octal characters.
 
 It is a compile time error if a backslash character in a character or
diff --git a/spec/03-types.md b/spec/03-types.md
index 4a02c7a8c1..29e6426530 100644
--- a/spec/03-types.md
+++ b/spec/03-types.md
@@ -231,7 +231,7 @@ SimpleType    ::=   ‘(’ Types ‘)’
 ```
 
 A tuple type $(T_1 , \ldots , T_n)$ is an alias for the
-class `scala.Tuple$_n$[$T_1$, … , $T_n$]`, where $n \geq 2$.
+class `scala.Tuple$n$[$T_1$, … , $T_n$]`, where $n \geq 2$.
 
 Tuple classes are case classes whose fields can be accessed using
 selectors `_1` , … , `_n`. Their functionality is
@@ -241,12 +241,12 @@ standard Scala library (they might also add other methods and
 implement other traits).
 
 ```scala
-case class Tuple$n$[+T1, … , +$T_n$](_1: T1, … , _n: $T_n$) 
-extends Product_n[T1, … , $T_n$]
+case class Tuple$n$[+$T_1$, … , +$T_n$](_1: $T_1$, … , _n: $T_n$)
+extends Product_n[$T_1$, … , $T_n$]
 
-trait Product_n[+T1, … , +$T_n$] {
+trait Product_n[+$T_1$, … , +$T_n$] {
   override def productArity = $n$
-  def _1: T1
+  def _1: $T_1$
   …
   def _n: $T_n$
 }
@@ -362,7 +362,7 @@ operators are left-associative.
 
 In a sequence of consecutive type infix operations 
 $t_0 \, \mathit{op} \, t_1 \, \mathit{op_2} \, \ldots \, \mathit{op_n} \, t_n$,
-all operators $\mathit{op}_1 , \ldots , \mathit{op}_n$ must have the same
+all operators $\mathit{op}\_1 , \ldots , \mathit{op}\_n$ must have the same
 associativity. If they are all left-associative, the sequence is
 interpreted as 
 $(\ldots (t_0 \mathit{op_1} t_1) \mathit{op_2} \ldots) \mathit{op_n} t_n$,
@@ -420,10 +420,10 @@ where $Q$ is a sequence of
 [type declarations](04-basic-declarations-and-definitions.html#type-declarations-and-type-aliases).
 
 Let 
-$t_1[\mathit{tps}_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}_n] >: L_n <: U_n$ 
-be the types declared in $Q$ (any of the 
+$t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n$
+be the types declared in $Q$ (any of the
 type parameter sections `[ $\mathit{tps}_i$ ]` might be missing).
-The scope of each type $t_i$ includes the type $T$ and the existential clause 
+The scope of each type $t_i$ includes the type $T$ and the existential clause
 $Q$. 
 The type variables $t_i$ are said to be _bound_ in the type 
 `$T$ forSome { $Q$ }`.
@@ -438,7 +438,7 @@ is the union of the set of values of all its type instances.
 
 A _skolemization_ of `$T$ forSome { $Q$ }` is
 a type instance $\sigma T$, where $\sigma$ is the substitution
-$[t'_1/t_1 , \ldots , t'_n/t_n]$ and each $t'_i$ is a fresh abstract type
+$[t_1'/t_1 , \ldots , t_n'/t_n]$ and each $t_i'$ is a fresh abstract type
 with lower bound $\sigma L_i$ and upper bound $\sigma U_i$.
 
 #### Simplification Rules
@@ -579,8 +579,8 @@ represents named methods that take arguments named $p_1 , \ldots , p_n$
 of types $T_1 , \ldots , T_n$
 and that return a result of type $U$.
 
-Method types associate to the right: $(\mathit{Ps}_1)(\mathit{Ps}_2)U$ is
-treated as $(\mathit{Ps}_1)((\mathit{Ps}_2)U)$.
+Method types associate to the right: $(\mathit{Ps}\_1)(\mathit{Ps}\_2)U$ is
+treated as $(\mathit{Ps}\_1)((\mathit{Ps}\_2)U)$.
 
 A special case are types of methods without any parameters. They are
 written here `=> T`. Parameterless methods name expressions
@@ -634,7 +634,7 @@ produce the typings
 
 ```scala
 empty : [A >: Nothing <: Any] List[A]
-union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A]  .
+union : [A >: Nothing <: Comparable[A]] (x: Set[A], xs: Set[A]) Set[A]
 ```
 
 ### Type Constructors
@@ -893,7 +893,7 @@ transitive relation that satisfies the following conditions.
 - Type constructors $T$ and $T'$ follow a similar discipline. We characterize 
   $T$ and $T'$ by their type parameter clauses
   $[a_1 , \ldots , a_n]$ and
-  $[a'_1 , \ldots , a'_n ]$, where an $a_i$ or $a'_i$ may include a variance 
+  $[a_1' , \ldots , a_n']$, where an $a_i$ or $a_i'$ may include a variance 
   annotation, a higher-order type parameter clause, and bounds. Then, $T$ 
   conforms to $T'$ if any list $[t_1 , \ldots , t_n]$ -- with declared 
   variances, bounds and higher-order type parameter clauses -- of valid type 
diff --git a/spec/04-basic-declarations-and-definitions.md b/spec/04-basic-declarations-and-definitions.md
index ab1f98ea07..358a4765ff 100644
--- a/spec/04-basic-declarations-and-definitions.md
+++ b/spec/04-basic-declarations-and-definitions.md
@@ -111,7 +111,7 @@ ids          ::=  id {‘,’ id}
 ```
 
 A value declaration `val $x$: $T$` introduces $x$ as a name of a value of
-type $T$.  
+type $T$.
 
 A value definition `val $x$: $T$ = $e$` defines $x$ as a
 name of the value that results from the evaluation of $e$. 
@@ -152,7 +152,7 @@ $\ldots$
 val $x_n$ = $\$ x$._n  .
 ```
 
-Here, $\$ x$ is a fresh name.  
+Here, $\$ x$ is a fresh name.
 
 2. If $p$ has a unique bound variable $x$:
 
@@ -339,13 +339,13 @@ A _type alias_ `type $t$ = $T$` defines $t$ to be an alias
 name for the type $T$.  The left hand side of a type alias may
 have a type parameter clause, e.g. `type $t$[$\mathit{tps}\,$] = $T$`.  The scope
 of a type parameter extends over the right hand side $T$ and the
-type parameter clause $\mathit{tps}$ itself.  
+type parameter clause $\mathit{tps}$ itself.
 
 The scope rules for [definitions](#basic-declarations-and-definitions) 
 and [type parameters](#function-declarations-and-definitions)
 make it possible that a type name appears in its
 own bound or in its right-hand side.  However, it is a static error if
-a type alias refers recursively to the defined type constructor itself.  
+a type alias refers recursively to the defined type constructor itself.
 That is, the type $T$ in a type alias `type $t$[$\mathit{tps}\,$] = $T$` may not 
 refer directly or indirectly to the name $t$.  It is also an error if
 an abstract type is directly or indirectly its own upper or lower bound.
@@ -436,9 +436,9 @@ TODO: this is a pretty awkward description of scoping and distinctness of binder
 
 The names of all type parameters must be pairwise different in their enclosing type parameter clause.  The scope of a type parameter includes in each case the whole type parameter clause. Therefore it is possible that a type parameter appears as part of its own bounds or the bounds of other type parameters in the same clause.  However, a type parameter may not be bounded directly or indirectly by itself.
 
-A type constructor parameter adds a nested type parameter clause to the type parameter. The most general form of a type constructor parameter is `$@a_1\ldots@a_n$ $\pm$ $t[\mathit{tps}\,]$ >: $L$ <: $U$`.  
+A type constructor parameter adds a nested type parameter clause to the type parameter. The most general form of a type constructor parameter is `$@a_1\ldots@a_n$ $\pm$ $t[\mathit{tps}\,]$ >: $L$ <: $U$`.
 
-The above scoping restrictions are generalized to the case of nested type parameter clauses, which declare higher-order type parameters. Higher-order type parameters (the type parameters of a type parameter $t$) are only visible in their immediately surrounding parameter clause (possibly including clauses at a deeper nesting level) and in the bounds of $t$. Therefore, their names must only be pairwise different from the names of other visible parameters. Since the names of higher-order type parameters are thus often irrelevant, they may be denoted with a ‘_’, which is nowhere visible.
+The above scoping restrictions are generalized to the case of nested type parameter clauses, which declare higher-order type parameters. Higher-order type parameters (the type parameters of a type parameter $t$) are only visible in their immediately surrounding parameter clause (possibly including clauses at a deeper nesting level) and in the bounds of $t$. Therefore, their names must only be pairwise different from the names of other visible parameters. Since the names of higher-order type parameters are thus often irrelevant, they may be denoted with a `‘_’`, which is nowhere visible.
 
 ###### Example
 Here are some well-formed type parameter clauses:
@@ -498,7 +498,7 @@ changes at the following constructs.
 - The variance position of a type parameter is the opposite of the
   variance position of the enclosing type parameter clause.
 - The variance position of the lower bound of a type declaration or type parameter 
-  is the opposite of the variance position of the type declaration or parameter.  
+  is the opposite of the variance position of the type declaration or parameter.
 - The type of a mutable variable is always in invariant position.
 - The right-hand side of a type alias is always in invariant position.
 - The prefix $S$ of a type selection `$S$#$T$` is always in invariant position.
@@ -628,7 +628,7 @@ A type parameter clause $\mathit{tps}$ consists of one or more
 [type declarations](#type-declarations-and-type-aliases), which introduce type 
 parameters, possibly with bounds.  The scope of a type parameter includes
 the whole signature, including any of the type parameter bounds as
-well as the function body, if it is present.  
+well as the function body, if it is present.
 
 A value parameter clause $\mathit{ps}$ consists of zero or more formal
 parameter bindings such as `$x$: $T$` or `$x: T = e$`, which bind value
@@ -708,7 +708,7 @@ ParamType          ::=  Type ‘*’
 ```
 
 The last value parameter of a parameter section may be suffixed by
-“*”, e.g. `(..., $x$:$T$*)`.  The type of such a
+`'*'`, e.g. `(..., $x$:$T$*)`.  The type of such a
 _repeated_ parameter inside the method is then the sequence type
 `scala.Seq[$T$]`.  Methods with repeated parameters
 `$T$*` take a variable number of arguments of type $T$.
@@ -878,7 +878,7 @@ The most general form of an import expression is a list of _import selectors_
 { $x_1$ => $y_1 , \ldots , x_n$ => $y_n$, _ } 
 ```
 
-for $n \geq 0$, where the final wildcard ‘_’ may be absent.  It
+for $n \geq 0$, where the final wildcard `‘_’` may be absent.  It
 makes available each importable member `$p$.$x_i$` under the unqualified name
 $y_i$. I.e. every import selector `$x_i$ => $y_i$` renames
 `$p$.$x_i$` to
diff --git a/spec/05-classes-and-objects.md b/spec/05-classes-and-objects.md
index 70fa3e0272..429f0b75bc 100644
--- a/spec/05-classes-and-objects.md
+++ b/spec/05-classes-and-objects.md
@@ -339,7 +339,8 @@ $M'$:
 - If $M$ is labeled `private[$C$]` for some enclosing class or package $C$,
   then $M'$ must be labeled `private[$C'$]` for some class or package $C'$ where
   $C'$ equals $C$ or $C'$ is contained in $C$.
-  <!-- TODO: check whether this is accurate -->
+
+<!-- TODO: check whether this is accurate -->
 - If $M$ is labeled `protected`, then $M'$ must also be
   labeled `protected`.
 - If $M'$ is not an abstract member, then $M$ must be labeled `override`.
@@ -699,7 +700,7 @@ ClassTemplateOpt  ::=  `extends' ClassTemplate | [[`extends'] TemplateBody]
 The most general form of class definition is 
 
 ```scala
-class $c$[$\mathit{tps}\,$] $as$ $m$($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) extends $t$    $\gap(n \geq 0)$.
+class $c$[$\mathit{tps}\,$] $as$ $m$($\mathit{ps}_1$)$\ldots$($\mathit{ps}_n$) extends $t$    $\quad(n \geq 0)$.
 ```
 
 Here,
@@ -719,7 +720,7 @@ Here,
   - $m$ is an [access modifier](#modifiers) such as
     `private` or `protected`, possibly with a qualification.
     If such an access modifier is given it applies to the primary constructor of the class.
-  - $(\mathit{ps}_1)\ldots(\mathit{ps}_n)$ are formal value parameter clauses for
+  - $(\mathit{ps}\_1)\ldots(\mathit{ps}\_n)$ are formal value parameter clauses for
     the _primary constructor_ of the class. The scope of a formal value parameter includes
     all subsequent parameter sections and the template $t$. However, a formal 
     value parameter may not form part of the types of any of the parent classes or members of the class template $t$.
@@ -885,10 +886,10 @@ object $c$ {
 
 Here, $\mathit{Ts}$ stands for the vector of types defined in the type
 parameter section $\mathit{tps}$,
-each $\mathit{xs}_i$ denotes the parameter names of the parameter
-section $\mathit{ps}_i$, and
-$\mathit{xs}_{11}, \ldots , \mathit{xs}_{1k}$ denote the names of all parameters
-in the first parameter section $\mathit{xs}_1$.
+each $\mathit{xs}\_i$ denotes the parameter names of the parameter
+section $\mathit{ps}\_i$, and
+$\mathit{xs}\_{11}, \ldots , \mathit{xs}\_{1k}$ denote the names of all parameters
+in the first parameter section $\mathit{xs}\_1$.
 If a type parameter section is missing in the
 class, it is also missing in the `apply` and
 `unapply` methods.
@@ -919,9 +920,9 @@ def copy[$\mathit{tps}\,$]($\mathit{ps}'_1\,$)$\ldots$($\mathit{ps}'_n$): $c$[$\
 ```
 
 Again, `$\mathit{Ts}$` stands for the vector of types defined in the type parameter section `$\mathit{tps}$`
-and each `$\xs_i$` denotes the parameter names of the parameter section `$\ps'_i$`. The value
-parameters `$\ps'_{1,j}$` of first parameter list have the form `$x_{1,j}$:$T_{1,j}$=this.$x_{1,j}$`,
-the other parameters `$\ps'_{i,j}$` of the `copy` method are defined as `$x_{i,j}$:$T_{i,j}$`.
+and each `$xs_i$` denotes the parameter names of the parameter section `$ps'_i$`. The value
+parameters `$ps'_{1,j}$` of first parameter list have the form `$x_{1,j}$:$T_{1,j}$=this.$x_{1,j}$`,
+the other parameters `$ps'_{i,j}$` of the `copy` method are defined as `$x_{i,j}$:$T_{i,j}$`.
 In all cases `$x_{i,j}$` and `$T_{i,j}$` refer to the name and type of the corresponding class parameter
 `$\mathit{ps}_{i,j}$`.
 
diff --git a/spec/06-expressions.md b/spec/06-expressions.md
index b2144aac6d..7e0a5facf1 100644
--- a/spec/06-expressions.md
+++ b/spec/06-expressions.md
@@ -62,12 +62,12 @@ $T$, then the type of the expression is assumed instead to be a
 [skolemization](03-types.html#existential-types) of $T$.
 
 Skolemization is reversed by type packing. Assume an expression $e$ of
-type $T$ and let $t_1[\mathit{tps}_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}_n] >: L_n <: U_n$ be
+type $T$ and let $t_1[\mathit{tps}\_1] >: L_1 <: U_1 , \ldots , t_n[\mathit{tps}\_n] >: L_n <: U_n$ be
 all the type variables created by skolemization of some part of $e$ which are free in $T$.
 Then the _packed type_ of $e$ is
 
 ```scala
-$T$ forSome { type $t_1[\mathit{tps}_1] >: L_1 <: U_1$; $\ldots$; type $t_n[\mathit{tps}_n] >: L_n <: U_n$ }.
+$T$ forSome { type $t_1[\mathit{tps}\_1] >: L_1 <: U_1$; $\ldots$; type $t_n[\mathit{tps}\_n] >: L_n <: U_n$ }.
 ```
 
 
@@ -269,7 +269,7 @@ it has the form $x_i=e'_i$ and $x_i$ is one of the parameter names
 $p_1 , \ldots , p_n$. The function $f$ is applicable if all of the following conditions
 hold:
 
-- For every named argument $x_i=e'_i$ the type $S_i$
+- For every named argument $x_i=e_i'$ the type $S_i$
   is compatible with the parameter type $T_j$ whose name $p_j$ matches $x_i$.
 - For every positional argument $e_i$ the type $S_i$
 is compatible with $T_i$.
@@ -388,7 +388,7 @@ the form
 }
 ```
 
-where every argument in $(\mathit{args}_1) , \ldots , (\mathit{args}_l)$ is a reference to
+where every argument in $(\mathit{args}\_1) , \ldots , (\mathit{args}\_l)$ is a reference to
 one of the values $x_1 , \ldots , x_k$. To integrate the current application
 into the block, first a value definition using a fresh name $y_i$ is created
 for every argument in $e_1 , \ldots , e_m$, which is initialised to $e_i$ for
@@ -700,18 +700,18 @@ parts of an expression as follows.
   expression, then operators with higher precedence bind more closely
   than operators with lower precedence.
 - If there are consecutive infix
-  operations $e_0; \mathit{op}_1; e_1; \mathit{op}_2 \ldots \mathit{op}_n; e_n$ 
-  with operators $\mathit{op}_1 , \ldots , \mathit{op}_n$ of the same precedence, 
+  operations $e_0; \mathit{op}\_1; e_1; \mathit{op}\_2 \ldots \mathit{op}\_n; e_n$ 
+  with operators $\mathit{op}\_1 , \ldots , \mathit{op}\_n$ of the same precedence, 
   then all these operators must
   have the same associativity. If all operators are left-associative,
   the sequence is interpreted as
-  $(\ldots(e_0;\mathit{op}_1;e_1);\mathit{op}_2\ldots);\mathit{op}_n;e_n$. 
+  $(\ldots(e_0;\mathit{op}\_1;e_1);\mathit{op}\_2\ldots);\mathit{op}\_n;e_n$. 
   Otherwise, if all operators are right-associative, the
   sequence is interpreted as
-  $e_0;\mathit{op}_1;(e_1;\mathit{op}_2;(\ldots \mathit{op}_n;e_n)\ldots)$.
+  $e_0;\mathit{op}\_1;(e_1;\mathit{op}\_2;(\ldots \mathit{op}\_n;e_n)\ldots)$.
 - Postfix operators always have lower precedence than infix
-  operators. E.g. $e_1;\mathit{op}_1;e_2;\mathit{op}_2$ is always equivalent to
-  $(e_1;\mathit{op}_1;e_2);\mathit{op}_2$.
+  operators. E.g. $e_1;\mathit{op}\_1;e_2;\mathit{op}\_2$ is always equivalent to
+  $(e_1;\mathit{op}\_1;e_2);\mathit{op}\_2$.
 
 The right-hand operand of a left-associative operator may consist of
 several arguments enclosed in parentheses, e.g. $e;\mathit{op};(e_1,\ldots,e_n)$.
@@ -817,12 +817,12 @@ the invocation of an `update` function defined by $f$.
 ###### Example
 Here are some assignment expressions and their equivalent expansions.
 
---------------------------    ---------------------
-`x.f = e`             x.f_=(e)
-`x.f() = e`           x.f.update(e)
-`x.f(i) = e`          x.f.update(i, e)
-`x.f(i, j) = e`       x.f.update(i, j, e)
---------------------------    ---------------------
+| assignment               | expansion            |
+|--------------------------|----------------------|
+|`x.f = e`                 | `x.f_=(e)`           |
+|`x.f() = e`               | `x.f.update(e)`      |
+|`x.f(i) = e`              | `x.f.update(i, e)`   |
+|`x.f(i, j) = e`           | `x.f.update(i, j, e)`|
 
 ### Example
 
diff --git a/spec/07-implicit-parameters-and-views.md b/spec/07-implicit-parameters-and-views.md
index 1a4d70409c..e07adc9e82 100644
--- a/spec/07-implicit-parameters-and-views.md
+++ b/spec/07-implicit-parameters-and-views.md
@@ -203,14 +203,14 @@ the type:
 - For a singleton type,  $\mathit{ttcs}(p.type) ~=~ \mathit{ttcs}(T)$, provided $p$ has type $T$;
 - For a compound type, `$\mathit{ttcs}(T_1$ with $\ldots$ with $T_n)$` $~=~ \mathit{ttcs}(T_1) \cup \ldots \cup \mathit{ttcs}(T_n)$.
 
-The _complexity_ $\mathit{complexity}(T)$ of a core type is an integer which also depends on the form of
+The _complexity_ $\operatorname{complexity}(T)$ of a core type is an integer which also depends on the form of
 the type:
 
-- For a type designator, $\mathit{complexity}(p.c) ~=~ 1 + \mathit{complexity}(p)$
-- For a parameterized type, $\mathit{complexity}(p.c[\mathit{targs}]) ~=~ 1 + \Sigma \mathit{complexity}(\mathit{targs})$
-- For a singleton type denoting a package $p$, $\mathit{complexity}(p.type) ~=~ 0$
-- For any other singleton type, $\mathit{complexity}(p.type) ~=~ 1 + \mathit{complexity}(T)$, provided $p$ has type $T$;
-- For a compound type, `$\mathit{complexity}(T_1$ with $\ldots$ with $T_n)$` $= \Sigma\mathit{complexity}(T_i)$
+- For a type designator, $\operatorname{complexity}(p.c) ~=~ 1 + \operatorname{complexity}(p)$
+- For a parameterized type, $\operatorname{complexity}(p.c[\mathit{targs}]) ~=~ 1 + \Sigma \operatorname{complexity}(\mathit{targs})$
+- For a singleton type denoting a package $p$, $\operatorname{complexity}(p.type) ~=~ 0$
+- For any other singleton type, $\operatorname{complexity}(p.type) ~=~ 1 + \operatorname{complexity}(T)$, provided $p$ has type $T$;
+- For a compound type, `$\operatorname{complexity}(T_1$ with $\ldots$ with $T_n)$` $= \Sigma\operatorname{complexity}(T_i)$
 
 
 ###### Example
diff --git a/spec/08-pattern-matching.md b/spec/08-pattern-matching.md
index 7b4d070181..6f71196b0d 100644
--- a/spec/08-pattern-matching.md
+++ b/spec/08-pattern-matching.md
@@ -63,7 +63,7 @@ patterns.
 A variable pattern $x$ is a simple identifier which starts with a
 lower case letter.  It matches any value, and binds the variable name
 to that value.  The type of $x$ is the expected type of the pattern as
-given from outside.  A special case is the wild-card pattern $\_$
+given from outside.  A special case is the wild-card pattern `_`
 which is treated as if it was a fresh variable on each occurrence.
 
 ### Typed Patterns
@@ -100,7 +100,7 @@ and it binds the variable name to that value.
 ```
 
 A literal pattern $L$ matches any value that is equal (in terms of
-$==$) to the literal $L$. The type of $L$ must conform to the
+`==`) to the literal $L$. The type of $L$ must conform to the
 expected type of the pattern.
 
 ### Stable Identifier Patterns
@@ -346,7 +346,7 @@ A type pattern $T$ is of one of the following  forms:
   the type patterns $T_i$.
 
 * A parameterized type pattern $T[a_1 , \ldots , a_n]$, where the $a_i$
-  are type variable patterns or wildcards $\_$. 
+  are type variable patterns or wildcards `_`. 
   This type pattern matches all values which match $T$ for
   some arbitrary instantiation of the type variables and wildcards. The
   bounds or alias type of these type variable are determined as
@@ -377,62 +377,64 @@ pattern.
 ### Type parameter inference for typed patterns.
 
 Assume a typed pattern $p: T'$. Let $T$ result from $T'$ where all wildcards in
-$T'$ are renamed to fresh variable names.  Let $a_1 , \ldots , a_n$ be
+$T'$ are renamed to fresh variable names. Let $a_1 , \ldots , a_n$ be
 the type variables in $T$. These type variables are considered bound
 in the pattern. Let the expected type of the pattern be $\mathit{pt}$.
 
 Type parameter inference constructs first a set of subtype constraints over
-the type variables $a_i$. The initial constraints set $\mathcal{C}_0$ reflects
+the type variables $a_i$. The initial constraints set $\mathcal{C}\_0$ reflects
 just the bounds of these type variables. That is, assuming $T$ has
 bound type variables $a_1 , \ldots , a_n$ which correspond to class
-type parameters $a'_1 , \ldots , a'_n$ with lower bounds $L_1, \ldots , L_n$
+type parameters $a_1' , \ldots , a_n'$ with lower bounds $L_1, \ldots , L_n$
 and upper bounds $U_1 , \ldots , U_n$, $\mathcal{C}_0$ contains the constraints 
 
-|             |      |               |                        |
-|-------------|------|---------------|------------------------|
-|$a_i$        | $<:$ | $\sigma U_i$  | $(i = 1, \ldots , n)$  |
-|$\sigma L_i$ | $<:$ | $a_i$         | $(i = 1 , \ldots , n)$ |
+$$
+\begin{cases}
+a_i &<: \sigma U_i & \quad (i = 1, \ldots , n) \\\\
+\sigma L_i &<: a_i & \quad (i = 1, \ldots , n)
+\end{cases}
+$$
 
 
-where $\sigma$ is the substitution $[a'_1 := a_1 , \ldots , a'_n :=
-a_n]$.
+where $\sigma$ is the substitution $[a_1' := a_1 , \ldots , a_n' :=a_n]$.
 
 The set $\mathcal{C}_0$ is then augmented by further subtype constraints. There are two
 cases.
 
 ###### Case 1
-If there exists a substitution $\sigma$ over the type variables $a_i , \ldots , a_n$ such that $\sigma T$ conforms to $\mathit{pt}$, one determines the weakest subtype constraints $\mathcal{C}_1$ over the type variables $a_1, \ldots , a_n$ such that $\mathcal{C}_0 \wedge \mathcal{C}_1$ implies that $T$ conforms to $\mathit{pt}$.
+If there exists a substitution $\sigma$ over the type variables $a_i , \ldots , a_n$ such that $\sigma T$ conforms to $\mathit{pt}$, one determines the weakest subtype constraints
+$\mathcal{C}\_1$ over the type variables $a_1, \ldots , a_n$ such that $\mathcal{C}\_0 \wedge \mathcal{C}_1$ implies that $T$ conforms to $\mathit{pt}$.
 
 ###### Case 2
 Otherwise, if $T$ can not be made to conform to $\mathit{pt}$ by
 instantiating its type variables, one determines all type variables in
 $\mathit{pt}$ which are defined as type parameters of a method enclosing
 the pattern. Let the set of such type parameters be $b_1 , \ldots ,
-b_m$. Let $\mathcal{C}'_0$ be the subtype constraints reflecting the bounds of the
+b_m$. Let $\mathcal{C}\_0'$ be the subtype constraints reflecting the bounds of the
 type variables $b_i$.  If $T$ denotes an instance type of a final
-class, let $\mathcal{C}_2$ be the weakest set of subtype constraints over the type
+class, let $\mathcal{C}\_2$ be the weakest set of subtype constraints over the type
 variables $a_1 , \ldots , a_n$ and $b_1 , \ldots , b_m$ such that
-$\mathcal{C}_0 \wedge \mathcal{C}'_0 \wedge \mathcal{C}_2$ implies that $T$ conforms to
+$\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}\_2$ implies that $T$ conforms to
 $\mathit{pt}$.  If $T$ does not denote an instance type of a final class,
-let $\mathcal{C}_2$ be the weakest set of subtype constraints over the type variables
-$a_1 , \ldots , a_n$ and $b_1 , \ldots , b_m$ such that $\mathcal{C}_0 \wedge
-\mathcal{C}'_0 \wedge \mathcal{C}_2$ implies that it is possible to construct a type
+let $\mathcal{C}\_2$ be the weakest set of subtype constraints over the type variables
+$a_1 , \ldots , a_n$ and $b_1 , \ldots , b_m$ such that $\mathcal{C}\_0 \wedge
+\mathcal{C}\_0' \wedge \mathcal{C}\_2$ implies that it is possible to construct a type
 $T'$ which conforms to both $T$ and $\mathit{pt}$. It is a static error if
-there is no satisfiable set of constraints $\mathcal{C}_2$ with this property.
+there is no satisfiable set of constraints $\mathcal{C}\_2$ with this property.
 
 The final step consists in choosing type bounds for the type
 variables which imply the established constraint system. The process
 is different for the two cases above.
 
 ###### Case 1
-We take $a_i >: L_i <: U_i$ where each $L_i$ is minimal and each $U_i$ is maximal wrt $<:$ such that $a_i >: L_i <: U_i$ for $i = 1, \ldots, n$ implies $\mathcal{C}_0 \wedge \mathcal{C}_1$.
+We take $a_i >: L_i <: U_i$ where each $L_i$ is minimal and each $U_i$ is maximal wrt $<:$ such that $a_i >: L_i <: U_i$ for $i = 1, \ldots, n$ implies $\mathcal{C}\_0 \wedge \mathcal{C}\_1$.
 
 ###### Case 2
-We take $a_i >: L_i <: U_i$ and $b_i >: L'_i <: U'_i$ where each $L_i$
-and $L'_j$ is minimal and each $U_i$ and $U'_j$ is maximal such that
+We take $a_i >: L_i <: U_i$ and $b\_i >: L_i' <: U_i' $ where each $L_i$
+and $L_j'$ is minimal and each $U_i$ and $U_j'$ is maximal such that
 $a_i >: L_i <: U_i$ for $i = 1 , \ldots , n$ and 
-$b_j >: L'_j <: U'_j$ for $j = 1 , \ldots , m$
-implies $\mathcal{C}_0 \wedge \mathcal{C}'_0 \wedge \mathcal{C}_2$.
+$b_j >: L_j' <: U_j'$ for $j = 1 , \ldots , m$
+implies $\mathcal{C}\_0 \wedge \mathcal{C}\_0' \wedge \mathcal{C}_2$.
 
 In both cases, local type inference is permitted to limit the
 complexity of inferred bounds. Minimality and maximality of types have
@@ -552,16 +554,16 @@ $T$ by replacing every occurrence of a type parameter $a_i$ by
 \mbox{\sl undefined}.  If this second step fails also, a compile-time
 error results. If the second step succeeds, let $T_p$ be the type of
 pattern $p$ seen as an expression. One then determines minimal bounds
-$L'_1 , \ldots , L'_m$ and maximal bounds $U'_1 , \ldots , U'_m$ such
-that for all $i$, $L_i <: L'_i$ and $U'_i <: U_i$ and the following
+$L_11 , \ldots , L_m'$ and maximal bounds $U_1' , \ldots , U_m'$ such
+that for all $i$, $L_i <: L_i'$ and $U_i' <: U_i$ and the following
 constraint system is satisfied:
 
 $$L_1 <: a_1 <: U_1\;\wedge\;\ldots\;\wedge\;L_m <: a_m <: U_m \ \Rightarrow\ T_p <: T$$
 
 If no such bounds can be found, a compile time error results.  If such
 bounds are found, the pattern matching clause starting with $p$ is
-then typed under the assumption that each $a_i$ has lower bound $L'_i$
-instead of $L_i$ and has upper bound $U'_i$ instead of $U_i$.
+then typed under the assumption that each $a_i$ has lower bound $L_i'$
+instead of $L_i$ and has upper bound $U_i'$ instead of $U_i$.
 
 The expected type of every block $b_i$ is the expected type of the
 whole pattern matching expression.  The type of the pattern matching
@@ -571,7 +573,7 @@ $b_i$.
 
 When applying a pattern matching expression to a selector value,
 patterns are tried in sequence until one is found which matches the
-[selector value](#patterns). Say this case is `$case p_i \Rightarrow b_i$`.
+[selector value](#patterns). Say this case is `case $p_i \Rightarrow b_i$`.
 The result of the whole expression is the result of evaluating $b_i$,
 where all pattern variables of $p_i$ are bound to
 the corresponding parts of the selector value.  If no matching pattern
diff --git a/spec/10-xml-expressions-and-patterns.md b/spec/10-xml-expressions-and-patterns.md
index d8c45ecf85..8d4b459844 100644
--- a/spec/10-xml-expressions-and-patterns.md
+++ b/spec/10-xml-expressions-and-patterns.md
@@ -37,10 +37,10 @@ Entity references are not resolved at runtime.
 Element       ::=    EmptyElemTag
                 |    STag Content ETag                                       
 
-EmptyElemTag  ::=    ‘<’ Name {S Attribute} [S] ‘/>’                         
+EmptyElemTag  ::=    ‘<’ Name {S Attribute} [S] ‘/>’
 
-STag          ::=    ‘<’ Name {S Attribute} [S] ‘>’                          
-ETag          ::=    ‘</’ Name [S] ‘>’                                        
+STag          ::=    ‘<’ Name {S Attribute} [S] ‘>’
+ETag          ::=    ‘</’ Name [S] ‘>’
 Content       ::=    [CharData] {Content1 [CharData]}
 Content1      ::=    XmlContent
                 |    Reference
@@ -68,7 +68,7 @@ character `\u0020`. This behavior can be changed to preserve all whitespace
 with a compiler option.
 
 ```ebnf
-Attribute  ::=    Name Eq AttValue                                    
+Attribute  ::=    Name Eq AttValue
 
 AttValue      ::=    ‘"’ {CharQ | CharRef} ‘"’
                 |    ‘'’ {CharA | CharRef} ‘'’
@@ -76,8 +76,8 @@ AttValue      ::=    ‘"’ {CharQ | CharRef} ‘"’
 
 ScalaExpr     ::=    Block
 
-CharData      ::=   { CharNoRef } $\mbox{\rm\em without}$ {CharNoRef}`{'CharB {CharNoRef} 
-                                  $\mbox{\rm\em and without}$ {CharNoRef}`]]>'{CharNoRef}
+CharData      ::=   { CharNoRef } $\textit{ without}$ {CharNoRef}`{'CharB {CharNoRef} 
+                                  $\textit{ and without}$ {CharNoRef}`]]>'{CharNoRef}
 ```
 
 <!-- {% raw  %} stupid liquid borks on the double brace below; brace yourself, liquid! -->
@@ -90,17 +90,17 @@ Thus, `{{` represents the XML text `{` and does not introduce an embedded Scala
 
 ```ebnf
 BaseChar, Char, Comment, CombiningChar, Ideographic, NameChar, S, Reference
-              ::=  $\mbox{\rm\em “as in W3C XML”}$
+              ::=  $\textit{“as in W3C XML”}$
 
-Char1         ::=  Char $\mbox{\rm\em without}$ ‘<’ | ‘&’
-CharQ         ::=  Char1 $\mbox{\rm\em without}$ ‘"’
-CharA         ::=  Char1 $\mbox{\rm\em without}$ ‘'’
-CharB         ::=  Char1 $\mbox{\rm\em without}$ ‘{’
+Char1         ::=  Char $\textit{ without}$ ‘<’ | ‘&’
+CharQ         ::=  Char1 $\textit{ without}$ ‘"’
+CharA         ::=  Char1 $\textit{ without}$ ‘'’
+CharB         ::=  Char1 $\textit{ without}$ ‘{’
 
 Name          ::=  XNameStart {NameChar}
 
 XNameStart    ::= ‘_’ | BaseChar | Ideographic 
-                 $\mbox{\rm\em (as in W3C XML, but without }$ ‘:’
+                 $\textit{ (as in W3C XML, but without }$ ‘:’$)$
 ```
 
 ## XML patterns
diff --git a/spec/12-the-scala-standard-library.md b/spec/12-the-scala-standard-library.md
index 9d4d69e52a..7ccbe0c9bd 100644
--- a/spec/12-the-scala-standard-library.md
+++ b/spec/12-the-scala-standard-library.md
@@ -86,8 +86,8 @@ class AnyRef extends Any {
 
   def synchronized[T](body: => T): T // execute `body` in while locking `this`.
 }                           
+```
 
-```scala
 The type test `$x$.isInstanceOf[$T$]` is equivalent to a typed
 pattern match