Revert "chore: format markdown"

This reverts commit edb690c.

Author: HerringtonDarkholme

website/advanced/custom-language.md

@@ -100,9 +100,9 @@ You need to add a new entry under the `customLanguages` key with the name of you
 ruleDirs: ["./rules"]
 customLanguages:
   mojo:
-    libraryPath: mojo.so # path to dynamic library
-    extensions: [mojo, 🔥] # file extensions for this language
-    expandoChar: _ # optional char to replace $ in your pattern
+      libraryPath: mojo.so     # path to dynamic library
+      extensions: [mojo, 🔥]   # file extensions for this language
+      expandoChar: _           # optional char to replace $ in your pattern
 ```
 
 The `libraryPath` property specifies the path to the dynamic library relative to the `sgconfig.yml` file or an absolute path. The `extensions` property specifies a list of file extensions for this language.
@@ -130,7 +130,7 @@ Or you can write a rule in yaml like this:
 
 ```yaml
 id: my-first-mojo-rule
-language: mojo # the name we register before!
+language: mojo  # the name we register before!
 severity: hint
 rule:
   pattern: print

website/advanced/faq.md

@@ -57,7 +57,7 @@ Different results are usually caused by incomplete or wrong code snippet in the
 ```yaml
 rule:
   pattern:
-    context: "int main() { return 0; }"
+    context: 'int main() { return 0; }'
     selector: function
 ```
 
@@ -113,7 +113,7 @@ The workaround is using [`constraints`](https://ast-grep.github.io/guide/project
 rule:
   pattern: $HOOK($$$ARGS)
 constraints:
-  HOOK: { regex: "^use" }
+  HOOK: { regex: '^use' }
 ```
 
 [Example usage](/playground.html#eyJtb2RlIjoiQ29uZmlnIiwibGFuZyI6ImphdmFzY3JpcHQiLCJxdWVyeSI6ImZvbygkJCRBLCBiLCAkJCRDKSIsInJld3JpdGUiOiIiLCJjb25maWciOiJydWxlOlxuICBwYXR0ZXJuOiAkSE9PSygkJCRBUkdTKVxuY29uc3RyYWludHM6XG4gIEhPT0s6IHsgcmVnZXg6IF51c2UgfSIsInNvdXJjZSI6ImZ1bmN0aW9uIFJlYWN0Q29tcG9uZW50KCkge1xuICAgIGNvbnN0IGRhdGEgPSBub3RIb28oKVxuICAgIGNvbnN0IFtmb28sIHNldEZvb10gPSB1c2VTdGF0ZSgnJylcbn0ifQ==).
@@ -153,10 +153,10 @@ id: recursive-call
 language: JavaScript
 rule:
   all:
-    - pattern: function $F() { $$$ }
-    - has:
-        pattern: $F()
-        stopBy: end
+  - pattern: function $F() { $$$ }
+  - has:
+      pattern: $F()
+      stopBy: end
 ```
 
 ```js [match.js]
@@ -177,10 +177,10 @@ id: recursive-call
 language: JavaScript
 rule:
   all:
-    - has: # N.B. has is the first rule
-        pattern: $F()
-        stopBy: end
-    - pattern: function $F() { $$$ }
+  - has:  # N.B. has is the first rule
+      pattern: $F()
+      stopBy: end
+  - pattern: function $F() { $$$ }
 ```
 
 In this case, the `has` rule matches first and captures `$F` as `foo` since `foo()` is the first function call matching the pattern `$F()`. The later rule `function $F() { $$$ }` will only find the `foo` declaration instead of `recurse`.
@@ -208,8 +208,8 @@ For example, to match class field in JavaScript, a kind + pattern rule [will not
 
 ```yaml
 # these are two separate rules
-pattern: a = 123 # rule 1
-kind: field_definition # rule 2
+pattern: a = 123          # rule 1
+kind: field_definition    # rule 2
 ```
 
 This is because pattern `a = 123` is parsed as [`assignment_expression`](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiYSA9IDEyMyIsInJld3JpdGUiOiIiLCJzdHJpY3RuZXNzIjoic21hcnQiLCJzZWxlY3RvciI6IiIsImNvbmZpZyI6IiIsInNvdXJjZSI6IiJ9). Pattern and kind are two separate rules. And using them together will match nothing because no AST will have both `assignment_expression` and `field_definition` kind at once.
@@ -219,8 +219,8 @@ Instead, you need to use pattern object to provide enough context code for the p
 ```yaml
 # this is one single pattern rule!
 pattern:
-  context: "class A { a = 123 }" # provide full context code
-  selector: field_definition # select the effective pattern
+  context: 'class A { a = 123 }' # provide full context code
+  selector: field_definition     # select the effective pattern
 ```
 
 Note the rule above is one single pattern rule, instead of two. The `context` field provides the full unambiguous code snippet of `class`. So the `a = 123` will be parsed as `field_definition`. The `selector` field then selects the `field_definition` node as the [effective pattern](/advanced/pattern-parse.html#steps-to-create-a-pattern) matcher.

website/advanced/find-n-patch.md

@@ -128,11 +128,11 @@ To do this, we register a rewriter that acts as a separate rewriter rule for eac
 
 ```yaml
 rewriters:
-  - id: rewrite-identifer
-    rule:
-      pattern: $IDENT
-      kind: identifier
-    fix: import $IDENT from './barrel/$IDENT'
+- id: rewrite-identifer
+  rule:
+    pattern: $IDENT
+    kind: identifier
+  fix: import $IDENT from './barrel/$IDENT'
 ```
 
 The `rewrite-identifier` above will:
@@ -168,11 +168,11 @@ The final rule will be like this. See the [online playground](https://ast-grep.g
 rule:
   pattern: import {$$$IDENTS} from './barrel'
 rewriters:
-  - id: rewrite-identifer
-    rule:
-      pattern: $IDENT
-      kind: identifier
-    fix: import $IDENT from './barrel/$IDENT'
+- id: rewrite-identifer
+  rule:
+    pattern: $IDENT
+    kind: identifier
+  fix: import $IDENT from './barrel/$IDENT'
 transform:
   IMPORTS:
     rewrite:

website/advanced/language-injection.md

@@ -111,10 +111,10 @@ You can add the `languageInjections` section in the project configuration file `
 
 ```yaml
 languageInjections:
-  - hostLanguage: js
-    rule:
-      pattern: styled.$TAG`$CONTENT`
-    injected: css
+- hostLanguage: js
+  rule:
+    pattern: styled.$TAG`$CONTENT`
+  injected: css
 ```
 
 Let's break the configuration down.
@@ -183,8 +183,8 @@ First, we need to register graphql as a custom language in ast-grep. See [custom
 customLanguages:
   graphql:
     libraryPath: graphql.so # the graphql tree-sitter parser dynamic library
-    extensions: [graphql] # graphql file extension
-    expandoChar: $ # see reference above for explanation
+    extensions: [graphql]   # graphql file extension
+    expandoChar: $          # see reference above for explanation
 ```
 
 ### Define graphql injection in `sgconfig.yml`.
@@ -193,10 +193,10 @@ Next, we need to customize what region should be parsed as graphql string in Jav
 
 ```yaml
 languageInjections:
-  - hostLanguage: js
-    rule:
-      pattern: graphql`$CONTENT`
-    injected: graphql
+- hostLanguage: js
+  rule:
+    pattern: graphql`$CONTENT`
+  injected: graphql
 ```
 
 ### Search GraphQL in JavaScript

website/advanced/pattern-parse.md

@@ -103,7 +103,7 @@ Without other hints, ast-grep will parse it as labeled statement by default. To
 
 ```yaml
 pattern:
-  context: "{ a: 123 }"
+  context: '{ a: 123 }'
   selector: pair
 ```
 
@@ -155,8 +155,8 @@ Examples:
 
 ```yaml
 program
-expression_statement
-number              <--- effective node
+  expression_statement
+    number              <--- effective node
 ```
 
 See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiMTIzIiwicmV3cml0ZSI6IiIsInN0cmljdG5lc3MiOiJzbWFydCIsInNlbGVjdG9yIjoiIiwiY29uZmlnIjoiIiwic291cmNlIjoiIn0=).
@@ -165,11 +165,11 @@ See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdC
 
 ```yaml
 program
-expression_statement
-call_expression       <--- effective node
-identifier
-arguments
-identifier
+  expression_statement
+    call_expression       <--- effective node
+      identifier
+      arguments
+        identifier
 ```
 
 See [Playground](/playground.html#eyJtb2RlIjoiUGF0Y2giLCJsYW5nIjoiamF2YXNjcmlwdCIsInF1ZXJ5IjoiZm9vKGJhcikiLCJyZXdyaXRlIjoiIiwic3RyaWN0bmVzcyI6InNtYXJ0Iiwic2VsZWN0b3IiOiJjYWxsX2V4cHJlc3Npb24iLCJjb25maWciOiIiLCJzb3VyY2UiOiIifQ==).

website/blog/yaml-vs-dsl.md

@@ -16,13 +16,15 @@ head:
   - - meta
     - property: og:description
       content: YAML and DSL are two different approaches to configure rule in structural search. The question "which is better" is largely subjective.
+
 ---
 
 # YAML vs DSL: comparison is subjective
 
 As stated in the [tool comparison](/advanced/tool-comparison.html#gritql), YAML configuration and DSL (Domain Specific Language) are two different approaches to configure rules in structural search. The question "which is better" is largely subjective.
 
-However, recently I have received some feedback that YAML is **objectively** not as good as DSL, and I would like to clarify some points.
+However, recently I have received some feedback that YAML is __objectively__ not as good as DSL, and I would like to clarify some points.
+
 
 The original argument is quoted as follows:
 
@@ -54,6 +56,7 @@ This argument is a [slippery slope fallacy](https://en.wikipedia.org/wiki/Slippe
 
 Using one concept in your library, framework or tool does not imply that you have to design a whole new syntax for it. The similar comparison will be frontend frameworks. Some frameworks like React and Vue use [hook](https://react.dev/reference/react/hooks) or [signals](https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob) to represent state changes. But using these building blocks does not grant the verdict to design a new language for your frontend framework. Even the most avant-garde company only introduces [new syntax](https://flow.org/en/docs/react/hook-syntax/) in JavaScript, not inventing a new language.
 
+
 ### Subjective opinion is not objective fact
 
 > I think GritQL queries are significantly easier to read than ast-grep's mix of DSL of YAML.
@@ -85,9 +88,9 @@ Biome's DSL is a mix of several different paradigms: declarative, logic, and imp
 }
 ```
 
-- `$method('$message')` is a declarative pattern matching syntax.
-- `where` and `<:` are related to [logic programming](https://en.wikipedia.org/wiki/Logic_programming#:~:text=Logic%20programming%20is%20a%20programming,solve%20problems%20in%20the%20domain.) paradigm, say, [Prolog](https://en.wikipedia.org/wiki/Prolog) or SQL.
-- `if` is a typical imperative programming paradigm
+* `$method('$message')` is a declarative pattern matching syntax.
+* `where` and `<:` are related to [logic programming](https://en.wikipedia.org/wiki/Logic_programming#:~:text=Logic%20programming%20is%20a%20programming,solve%20problems%20in%20the%20domain.) paradigm, say, [Prolog](https://en.wikipedia.org/wiki/Prolog) or SQL.
+* `if` is a typical imperative programming paradigm
 
 The mixture of paradigms does not blend well. At least, in the eye of a programming language veteran, it is too messy for a DSL for linting or structural search. We are not designing a next-era programming language.
 
@@ -156,9 +159,9 @@ They all look like function calls, but they are not. See explanation below for t
 
 These three concepts are very similar, but they have slightly different usage in the DSL.
 
-- `pattern` is used in `<:` or somewhere else, I dunno, the doc does not explain it well.
-- `predicate` is used in `where` condition.
-- `function` is used in `assignment`, `insertion` or `rewrite`.
+* `pattern` is used in `<:` or somewhere else, I dunno, the doc does not explain it well.
+* `predicate` is used in `where` condition.
+* `function` is used in `assignment`, `insertion` or `rewrite`.
 
 Example:
 
@@ -186,19 +189,19 @@ If you still have patience, you need one last thing to learn: variable scope.
 
 I have no better explanation for it since I don't understand it well, so I will quote the [official documentation](https://docs.grit.io/language/bubble):
 
-> Once a metavariable is bound to a value, it retains this value throughout the target code. Therefore, the scope of the metavariable spans the entire target file.
+>  Once a metavariable is bound to a value, it retains this value throughout the target code. Therefore, the scope of the metavariable spans the entire target file.
 
 To fully understand it, you also need to know `bubble`, `bubble($argument)` and pattern auto wrap.
 
 ## What can go even more wrong?
 
 Integrating a custom linting rule from another parser ecosystem to your own has several more decisions to make. Making bad decisions can lead to even more confusion.
 
-- Your pattern syntax includes non standard syntax, like `$...`. You need to [change your parser](https://github.com/biomejs/biome/blob/31e439674493da76e0ce213e5660be3d903efbef/crates/biome_js_parser/src/syntax/jsx/mod.rs#L321) to support it.
-- You need to make a decision if you want to support existing pattern libraries. But these patterns are built upon [tree-sitter](https://tree-sitter.github.io/tree-sitter/). So you have to [map tree-sitter AST to your own](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L42-L55)
-- Even worse, if you chose to support existing pattern libraries, you also need to work on a general algorithm to handle incompatibility between different ASTs. For example, different AST structures, different node names, different node properties, etc.
-- If you only supports part of it, how can you teach your users what is supported and what is not, without [reading the source](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L48-L50)?
-- You also need to update your playground or editor plugins to support mapping between tree-sitter AST and your own AST. And teach users to use it.
+* Your pattern syntax includes non standard syntax, like `$...`. You need to [change your parser](https://github.com/biomejs/biome/blob/31e439674493da76e0ce213e5660be3d903efbef/crates/biome_js_parser/src/syntax/jsx/mod.rs#L321) to support it.
+* You need to make a decision if you want to support existing pattern libraries. But these patterns are built upon [tree-sitter](https://tree-sitter.github.io/tree-sitter/). So you have to [map tree-sitter AST to your own](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L42-L55)
+* Even worse, if you chose to support existing pattern libraries, you also need to work on a general algorithm to handle incompatibility between different ASTs. For example, different AST structures, different node names, different node properties, etc.
+* If you only supports part of it, how can you teach your users what is supported and what is not, without [reading the source](https://github.com/biomejs/biome/blob/7bf9a608e1592fd595f658f5f800e12d51835d34/crates/biome_grit_patterns/src/grit_target_language/js_target_language.rs#L48-L50)?
+* You also need to update your playground or editor plugins to support mapping between tree-sitter AST and your own AST. And teach users to use it.
 
 ## Conclusion
 
@@ -210,11 +213,11 @@ If you are a library or framework author, you can make decision based on your ow
 
 Consider these points when you want to have objective comparison:
 
-- Documentation?
-- User Education? Howe you teach users to write your DSL?
-- Tooling support like [playground](/playground.html).
-- Editor support beyong syntax highlighting. Say LSP.
-- Integration with API, how you bring type-safe DSL into your general purpose programming language, like [graphql](https://github.com/Quramy/ts-graphql-plugin) and [styled component](https://github.com/styled-components/typescript-styled-plugin).
-- Broader ecosystem support, such as GitHub language detection, AI support, etc.
+* Documentation?
+* User Education? Howe you teach users to write your DSL?
+* Tooling support like [playground](/playground.html).
+* Editor support beyong syntax highlighting. Say LSP.
+* Integration with API, how you bring type-safe DSL into your general purpose programming language, like [graphql](https://github.com/Quramy/ts-graphql-plugin) and [styled component](https://github.com/styled-components/typescript-styled-plugin).
+* Broader ecosystem support, such as GitHub language detection, AI support, etc.
 
 If you are going to use native tooling in your JavaScript/TypeScript project, I recommend you to use [oxlint](https://oxc.rs/) and, if you need simple custom rules, [ast-grep](https://ast-grep.github.io/).

website/catalog/c/rewrite-method-to-function-call.md

@@ -26,8 +26,8 @@ transform:
   MAYBE_COMMA:
     replace:
       source: $$$ARGS
-      replace: "^.+"
-      by: ", "
+      replace: '^.+'
+      by: ', '
 fix:
   $METHOD(&$R$MAYBE_COMMA$$$ARGS)
 ```

website/catalog/c/yoda-condition.md

@@ -16,12 +16,12 @@ In programming jargon, a [Yoda condition](https://en.wikipedia.org/wiki/Yoda_con
 id: may-the-force-be-with-you
 language: c
 rule:
-  pattern: $A == $B # Find equality comparison
-  inside: # inside an if_statement
+  pattern: $A == $B                 # Find equality comparison
+  inside:                           # inside an if_statement
     kind: parenthesized_expression
-    inside: { kind: if_statement }
-constraints: # with the constraint that
-  B: { kind: number_literal } # right side is a number
+    inside: {kind: if_statement}
+constraints:                        # with the constraint that
+  B: { kind: number_literal }       # right side is a number
 fix: $B == $A
 ```
 

website/catalog/cpp/fix-format-vuln.md

@@ -25,8 +25,8 @@ constraints:
   VAR: # not a literal string
     not:
       any:
-        - { kind: string_literal }
-        - { kind: concatenated_string }
+      - { kind: string_literal }
+      - { kind: concatenated_string }
 fix: $PRINTF($S, "%s", $VAR)
 ```
 

website/catalog/go/match-function-call.md

@@ -20,7 +20,7 @@ id: match-function-call
 language: go
 rule:
   pattern:
-    context: "func t() { fmt.Println($A) }"
+    context: 'func t() { fmt.Println($A) }'
     selector: call_expression
 ```