Fix inline code formatting in JEPs (#140)

Author: gibson042

jep-001-nested-expressions.md

@@ -59,7 +59,7 @@ Given:
 }
 ```
 
-With: `foo.[baz[\*].bar, qux[0]]`
+With: `foo.[baz[*].bar, qux[0]]`
 
 Result:
 
@@ -96,7 +96,7 @@ Given:
 }
 ```
 
-With: `foo.[baz[\*].[bar, boo], qux[0]]`
+With: `foo.[baz[*].[bar, boo], qux[0]]`
 
 Result:
 
@@ -139,7 +139,7 @@ Given:
 }
 ```
 
-With: `foo.[baz[\*].not_there || baz[\*].bar, qux[0]]`
+With: `foo.[baz[*].not_there || baz[*].bar, qux[0]]`
 
 Result:
 

jep-003-functions.md

@@ -338,8 +338,8 @@ the string contains the provided `$search` argument.
 | n/a | ``contains(`false`, `bar`)`` | `<error: invalid-type>`
 | n/a | ``contains(`foobar`, 123)`` | `false`
 | `["a", "b"]` | ``contains(@, `a`)`` | `true`
-| `["a"]` | ``contains(@, `a\`)`` | `true`
-| `["a"]` | ``contains(@, `b\`)`` | `false`
+| `["a"]` | ``contains(@, `a`)`` | `true`
+| `["a"]` | ``contains(@, `b`)`` | `false`
 
 ### floor
 
@@ -353,9 +353,9 @@ Returns the next lowest integer value by rounding down if necessary.
 
 | Expression | Result
 |---|---
-| ``floor(`1.001\`)`` | 1
-| ``floor(`1.9\`)`` | 1 
-| ``floor(`1\`)`` | 1
+| ``floor(`1.001`)`` | 1
+| ``floor(`1.9`)`` | 1
+| ``floor(`1`)`` | 1
 
 ### join
 

jep-006-improved-identifiers.md

@@ -79,7 +79,7 @@ in XML (`&#nnnn`), JMESPath should support the same escape sequences
 used in JSON.  JSON also supports a 12 character escape sequence for
 characters outside of the BMP, by encoding the UTF-16 surrogate pair.
 For example, the code point `U+1D11E` can be represented
-as `"\\uD834\\uDD1E"`.
+as `"\uD834\uDD1E"`.
 
 ### Escape Sequences
 
@@ -98,14 +98,14 @@ in certain environments.  For example, in python, this is not a problem:
 >>> jmespath_expression = "foo\nbar"
 ```
 
-Python will interpret the sequence `"\\n"` (`%x5C %x6E`) as the newline
+Python will interpret the sequence `"\n"` (`%x5C %x6E`) as the newline
 character `%x0A`.  However, consider Bash:
 
 ```
 $ foo --jmespath-expression "foo\nbar"
 ```
 
-In this situation, bash will not interpret the `"\\n"` (`%x5C %x6E`)
+In this situation, bash will not interpret the `"\n"` (`%x5C %x6E`)
 sequence.
 
 ## Specification
@@ -226,11 +226,11 @@ This has to do with the updated escaping rules.  Each one will be explained.
           },
 ```
 
-This has to be updated because a JSON parser will interpret the `\\n` sequence
+This has to be updated because a JSON parser will interpret the `\n` sequence
 as the newline character.  The newline character is **not** allowed in a
 JMESPath identifier (note that the newline character `%0A` is not in any
 rule).  In order for a JSON parser to create a sequence of `%x5C %x6E`, the
-JSON string must be `\\\\n` (`%x5C %x5C %x6E`).
+JSON string must be `\\n` (`%x5C %x5C %x6E`).
 
 ```
 -            "expression": "\"c:\\\\windows\\path\"",
@@ -243,7 +243,7 @@ The above example is a more pathological case of escaping.  In this example, we
 have a string that represents a windows path “c:\\windowpath”.  There are two
 levels of escaping happening here, one at the JSON parser, and one at the
 JMESPath parser.  The JSON parser will take the sequence
-`"\\"c:\\\\\\\\\\\\\\\\windows\\\\\\\\path\\""` and create the string
-`"\\"c:\\\\\\\\windows\\\\path\\""`.  The JMESPath parser will take the string
-`"\\"c:\\\\\\\\windows\\\\path\\"'` and, applying its own escaping rules, will
-look for a key named `c:\\\\windows\\path`.
+`"\"c:\\\\\\\\windows\\\\path\""` and create the string
+`"\"c:\\\\windows\\path\""`.  The JMESPath parser will take the string
+`"\"c:\\\\windows\\path\"'` and, applying its own escaping rules, will
+look for a key named `c:\\windows\path`.

jep-007-filter-expressions.md

@@ -174,7 +174,7 @@ Using the previous example, given the following data:
          {"state": "CA", "value": 4}]}
 ```
 
-The expression `foo[?state == \`WA\`]` will return the following value:
+The expression ``foo[?state == `WA`]`` will return the following value:
 
 ```
 [{"state": "WA", "value": 1}]
@@ -184,7 +184,7 @@ The expression `foo[?state == \`WA\`]` will return the following value:
 
 Literal expressions are also added in the JEP, which is essentially a JSON
 value surrounded by the “\`” character.  You can escape the “\`” character via
-“\`”, and if the character “\`” appears in the JSON value, it must also be
+“\\`”, and if the character “\`” appears in the JSON value, it must also be
 escaped.  A simple two pass algorithm in the lexer could first process any
 escaped “\`” characters before handing the resulting string to a JSON parser.
 
@@ -262,7 +262,7 @@ list with a single integer value of 2:  `[foo == [2]]`.
 
 * Adding literal expressions makes them useful even outside of a filter
 expression.  For example, in a `multi-select-hash`, you can create
-arbitrary key value pairs:  `{a: foo.bar, b: \`some string\`}`.
+arbitrary key value pairs:  ``{a: foo.bar, b: `some string`}``.
 
 This JEP is purposefully minimal.  There are several extensions that can be
 added in future:

jep-010-slice-projections.md

@@ -28,7 +28,7 @@ This JEP proposes that a slice expression will create a projection.
 
 A reasonable objection to this JEP is that this is unnecessary because, as
 shown in the example above, you can take any slice and create a projection via
-`[\*]`.  This is entirely true, unlike other JEPs, this JEP does not enable
+`[*]`.  This is entirely true, unlike other JEPs, this JEP does not enable
 any behavior that was previously not possible.
 
 Instead, the main reason for this JEP is for consistency.  Right now there are

jep-011-let-function.md

@@ -174,7 +174,7 @@ Here we have nested let calls, and the expression we are trying to
 evaluate is the multiselect hash `{a: a, b: b, c: c}`.  The
 `c` identifier comes from the evaluation context `{"c": "z"}`.
 The `b` identifier comes from the scope object in the second `let`
-call: `{b: \`y\`}`.  And finally, here’s the lookup process for the
+call: ``{b: `y`}``.  And finally, here’s the lookup process for the
 `a` identifier:
 
 
@@ -187,7 +187,7 @@ call: `{b: \`y\`}`.  And finally, here’s the lookup process for the
 * Is there a parent scope?  Yes
 
 
-* Does the parent scope, `{a: \`x\`}`, define `a`?  Yes, `a` has
+* Does the parent scope, ``{a: `x`}``, define `a`?  Yes, `a` has
 the value of `"x"`, so `a` is resolved as the string `"x"`.
 
 ### Current Node Evaluation

jep-012-raw-string-literals.md

@@ -36,7 +36,7 @@ Raw string literals are provided in [various programming languages](https://en.w
 language specific interpretation (i.e., JSON parsing) and remove the need for
 escaping, avoiding a common problem called [leaning toothpick syndrome (LTS)](https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome). Leaning toothpick
 syndrome is an issue in which strings become unreadable due to excessive use of
-escape characters in order to avoid delimiter collision (e.g., `\\\\\\\\\\\\`).
+escape characters in order to avoid delimiter collision (e.g., `\\\\\\`).
 
 When evaluating a JMESPath expression, it is often necessary to utilize string
 literals that are not extracted from the data being evaluated, but rather
@@ -64,7 +64,7 @@ These string literals are parsed using a JSON parser according to
 escape sequences, newline characters, and several other escape sequences
 documented in RFC 4627 section 2.5.
 
-For example, the use of an escaped unicode value `\\u002B` is expanded into
+For example, the use of an escaped unicode value `\u002B` is expanded into
 `+` in the following JMESPath expression:
 
 ```
@@ -89,7 +89,7 @@ problems:
 2. Requires the cognitive overhead of escaping escape characters if you
 actually want the data to be represented as it was literally provided
 (which can lead to LTS). If the data being escaped was meant to be used
-along with another language that uses `\\` as an escape character, then the
+along with another language that uses `\` as an escape character, then the
 number of backslash characters doubles.
 
 
@@ -233,7 +233,7 @@ bar!
 
 
 * A raw string literal that contains escape characters,
-parsed as `foo\\nbar`:
+parsed as `foo\nbar`:
 
 ```
 foo\nbar