From 5374b4bd6ba15493d8459277090a53f213ecf913 Mon Sep 17 00:00:00 2001 From: Richard Gibson Date: Sun, 20 Nov 2022 08:23:47 -0500 Subject: [PATCH] Fix inline code formatting in JEPs (#140) --- jep-001-nested-expressions.md | 6 +++--- jep-003-functions.md | 10 +++++----- jep-006-improved-identifiers.md | 18 +++++++++--------- jep-007-filter-expressions.md | 6 +++--- jep-010-slice-projections.md | 2 +- jep-011-let-function.md | 4 ++-- jep-012-raw-string-literals.md | 8 ++++---- 7 files changed, 27 insertions(+), 27 deletions(-) diff --git a/jep-001-nested-expressions.md b/jep-001-nested-expressions.md index 4d4660c..201ff76 100644 --- a/jep-001-nested-expressions.md +++ b/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: diff --git a/jep-003-functions.md b/jep-003-functions.md index a0687a1..df730cc 100644 --- a/jep-003-functions.md +++ b/jep-003-functions.md @@ -338,8 +338,8 @@ the string contains the provided `$search` argument. | n/a | ``contains(`false`, `bar`)`` | `` | 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 diff --git a/jep-006-improved-identifiers.md b/jep-006-improved-identifiers.md index 00187ac..7210e7f 100644 --- a/jep-006-improved-identifiers.md +++ b/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`. diff --git a/jep-007-filter-expressions.md b/jep-007-filter-expressions.md index 4eba8b0..7bb5a78 100644 --- a/jep-007-filter-expressions.md +++ b/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: diff --git a/jep-010-slice-projections.md b/jep-010-slice-projections.md index 5cfe146..674a39d 100644 --- a/jep-010-slice-projections.md +++ b/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 diff --git a/jep-011-let-function.md b/jep-011-let-function.md index 2a95534..e3307c4 100644 --- a/jep-011-let-function.md +++ b/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 diff --git a/jep-012-raw-string-literals.md b/jep-012-raw-string-literals.md index 8372029..930d792 100644 --- a/jep-012-raw-string-literals.md +++ b/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