Fix nested lists in CONTRIBUTING.md (#5721)

## Summary

We have a lot of two-space-indented stuff, but apparently it needs to be
four-space indented to render as expected in MkDocs.

.markdownlint.yaml

@@ -1,6 +1,10 @@
 # default to true for all rules
 default: true
 
+# MD007/unordered-list-indent
+MD007:
+  indent: 4
+
 # MD033/no-inline-html
 MD033: false
 
@@ -8,7 +12,4 @@ MD033: false
 MD041: false
 
 # MD013/line-length
-MD013:
+MD013: false
-  line_length: 100
-  code_blocks: false
-  ignore_code_blocks: true

.pre-commit-config.yaml

@@ -22,6 +22,7 @@ repos:
     hooks:
       - id: mdformat
         additional_dependencies:
+          - mdformat-mkdocs
           - mdformat-black
           - black==23.1.0 # Must be the latest version of Black
 

BREAKING_CHANGES.md

@@ -48,12 +48,12 @@ Taking `UP006` (rewrite `List[int]` to `list[int]`) as an example, the setting n
 follows:
 
 - On Python 3.7 and Python 3.8, setting `keep-runtime-typing = true` will cause Ruff to ignore
-  `UP006` violations, even if `from __future__ import annotations` is present in the file.
+    `UP006` violations, even if `from __future__ import annotations` is present in the file.
-  While such annotations are valid in Python 3.7 and Python 3.8 when combined with
+    While such annotations are valid in Python 3.7 and Python 3.8 when combined with
-  `from __future__ import annotations`, they aren't supported by libraries like Pydantic and
+    `from __future__ import annotations`, they aren't supported by libraries like Pydantic and
-  FastAPI, which rely on runtime type checking.
+    FastAPI, which rely on runtime type checking.
 - On Python 3.9 and above, the setting has no effect, as `list[int]` is a valid type annotation,
-  and libraries like Pydantic and FastAPI support it without issue.
+    and libraries like Pydantic and FastAPI support it without issue.
 
 In short: `keep-runtime-typing` can be used to ensure that Ruff doesn't introduce type annotations
 that are not supported at runtime by the current Python version, which are unsupported by libraries
@@ -203,25 +203,25 @@ This change is largely backwards compatible -- most users should experience
 no change in behavior. However, please note the following exceptions:
 
 - Subcommands will now fail when invoked with unsupported arguments, instead
-  of silently ignoring them. For example, the following will now fail:
+    of silently ignoring them. For example, the following will now fail:
 
-  ```console
+    ```console
-  ruff --clean --respect-gitignore
+    ruff --clean --respect-gitignore
-  ```
+    ```
 
-  (the `clean` command doesn't support `--respect-gitignore`.)
+    (the `clean` command doesn't support `--respect-gitignore`.)
 
 - The semantics of `ruff <arg>` have changed slightly when `<arg>` is a valid subcommand.
-  For example, prior to this release, running `ruff rule` would run `ruff` over a file or
+    For example, prior to this release, running `ruff rule` would run `ruff` over a file or
-  directory called `rule`. Now, `ruff rule` would invoke the `rule` subcommand. This should
+    directory called `rule`. Now, `ruff rule` would invoke the `rule` subcommand. This should
-  only impact projects with files or directories named `rule`, `check`, `explain`, `clean`,
+    only impact projects with files or directories named `rule`, `check`, `explain`, `clean`,
-  or `generate-shell-completion`.
+    or `generate-shell-completion`.
 
 - Scripts that invoke ruff should supply `--` before any positional arguments.
-  (The semantics of `ruff -- <arg>` have not changed.)
+    (The semantics of `ruff -- <arg>` have not changed.)
 
 - `--explain` previously treated `--format grouped` as a synonym for `--format text`.
-  This is no longer supported; instead, use `--format text`.
+    This is no longer supported; instead, use `--format text`.
 
 ## 0.0.226
 

CODE_OF_CONDUCT.md

@@ -6,10 +6,10 @@
 - [Scope](#scope)
 - [Enforcement](#enforcement)
 - [Enforcement Guidelines](#enforcement-guidelines)
-  - [1. Correction](#1-correction)
+    - [1. Correction](#1-correction)
-  - [2. Warning](#2-warning)
+    - [2. Warning](#2-warning)
-  - [3. Temporary Ban](#3-temporary-ban)
+    - [3. Temporary Ban](#3-temporary-ban)
-  - [4. Permanent Ban](#4-permanent-ban)
+    - [4. Permanent Ban](#4-permanent-ban)
 - [Attribution](#attribution)
 
 ## Our Pledge
@@ -33,20 +33,20 @@ community include:
 - Being respectful of differing opinions, viewpoints, and experiences
 - Giving and gracefully accepting constructive feedback
 - Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
+    and learning from the experience
 - Focusing on what is best not just for us as individuals, but for the
-  overall community
+    overall community
 
 Examples of unacceptable behavior include:
 
 - The use of sexualized language or imagery, and sexual attention or
-  advances of any kind
+    advances of any kind
 - Trolling, insulting or derogatory comments, and personal or political attacks
 - Public or private harassment
 - Publishing others' private information, such as a physical or email
-  address, without their explicit permission
+    address, without their explicit permission
 - Other conduct which could reasonably be considered inappropriate in a
-  professional setting
+    professional setting
 
 ## Enforcement Responsibilities
 

CONTRIBUTING.md

@@ -3,13 +3,13 @@
 Welcome! We're happy to have you here. Thank you in advance for your contribution to Ruff.
 
 - [The Basics](#the-basics)
-  - [Prerequisites](#prerequisites)
+    - [Prerequisites](#prerequisites)
-  - [Development](#development)
+    - [Development](#development)
-  - [Project Structure](#project-structure)
+    - [Project Structure](#project-structure)
-  - [Example: Adding a new lint rule](#example-adding-a-new-lint-rule)
+    - [Example: Adding a new lint rule](#example-adding-a-new-lint-rule)
-    - [Rule naming convention](#rule-naming-convention)
+        - [Rule naming convention](#rule-naming-convention)
-    - [Rule testing: fixtures and snapshots](#rule-testing-fixtures-and-snapshots)
+        - [Rule testing: fixtures and snapshots](#rule-testing-fixtures-and-snapshots)
-  - [Example: Adding a new configuration option](#example-adding-a-new-configuration-option)
+    - [Example: Adding a new configuration option](#example-adding-a-new-configuration-option)
 - [MkDocs](#mkdocs)
 - [Release Process](#release-process)
 - [Benchmarks](#benchmarking-and-profiling)
@@ -23,9 +23,10 @@ For small changes (e.g., bug fixes), feel free to submit a PR.
 For larger changes (e.g., new lint rules, new functionality, new configuration options), consider
 creating an [**issue**](https://github.com/astral-sh/ruff/issues) outlining your proposed change.
 You can also join us on [**Discord**](https://discord.gg/c9MhzV8aU5) to discuss your idea with the
-community. We have labeled [beginner-friendly tasks in the issue tracker](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
+community. We've labeled [beginner-friendly tasks](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
-as well as [bugs](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Abug) and
+in the issue tracker, along with [bugs](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Abug)
-[improvements that are ready for contributions](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted).
+and [improvements](https://github.com/astral-sh/ruff/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted)
+that are ready for contributions.
 
 If you're looking for a place to start, we recommend implementing a new lint rule (see:
 [_Adding a new lint rule_](#example-adding-a-new-lint-rule), which will allow you to learn from and
@@ -100,19 +101,19 @@ At time of writing, the repository includes the following crates:
 - `crates/ruff_cache`: library crate for caching lint results.
 - `crates/ruff_cli`: binary crate containing Ruff's command-line interface.
 - `crates/ruff_dev`: binary crate containing utilities used in the development of Ruff itself (e.g.,
-  `cargo dev generate-all`).
+    `cargo dev generate-all`).
 - `crates/ruff_diagnostics`: library crate for the lint diagnostics APIs.
 - `crates/ruff_formatter`: library crate for generic code formatting logic based on an intermediate
-  representation.
+    representation.
 - `crates/ruff_index`: library crate inspired by `rustc_index`.
 - `crates/ruff_macros`: library crate containing macros used by Ruff.
 - `crates/ruff_python_ast`: library crate containing Python-specific AST types and utilities.
 - `crates/ruff_python_formatter`: library crate containing Python-specific code formatting logic.
 - `crates/ruff_python_semantic`: library crate containing Python-specific semantic analysis logic,
-  including Ruff's semantic model.
+    including Ruff's semantic model.
 - `crates/ruff_python_stdlib`: library crate containing Python-specific standard library data.
 - `crates/ruff_python_whitespace`: library crate containing Python-specific whitespace analysis
-  logic.
+    logic.
 - `crates/ruff_rustpython`: library crate containing `RustPython`-specific utilities.
 - `crates/ruff_testing_macros`: library crate containing macros used for testing Ruff.
 - `crates/ruff_textwrap`: library crate to indent and dedent Python source code.
@@ -123,21 +124,21 @@ At time of writing, the repository includes the following crates:
 At a high level, the steps involved in adding a new lint rule are as follows:
 
 1. Determine a name for the new rule as per our [rule naming convention](#rule-naming-convention)
-   (e.g., `AssertFalse`, as in, "allow `assert False`").
+    (e.g., `AssertFalse`, as in, "allow `assert False`").
 
 1. Create a file for your rule (e.g., `crates/ruff/src/rules/flake8_bugbear/rules/assert_false.rs`).
 
 1. In that file, define a violation struct (e.g., `pub struct AssertFalse`). You can grep for
-   `#[violation]` to see examples.
+    `#[violation]` to see examples.
 
 1. In that file, define a function that adds the violation to the diagnostic list as appropriate
-   (e.g., `pub(crate) fn assert_false`) based on whatever inputs are required for the rule (e.g.,
+    (e.g., `pub(crate) fn assert_false`) based on whatever inputs are required for the rule (e.g.,
-   an `ast::StmtAssert` node).
+    an `ast::StmtAssert` node).
 
 1. Define the logic for triggering the violation in `crates/ruff/src/checkers/ast/mod.rs` (for
-   AST-based checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks),
+    AST-based checks), `crates/ruff/src/checkers/tokens.rs` (for token-based checks),
-   `crates/ruff/src/checkers/lines.rs` (for text-based checks), or
+    `crates/ruff/src/checkers/lines.rs` (for text-based checks), or
-   `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based checks).
+    `crates/ruff/src/checkers/filesystem.rs` (for filesystem-based checks).
 
 1. Map the violation struct to a rule code in `crates/ruff/src/codes.rs` (e.g., `B011`).
 
@@ -170,13 +171,13 @@ suppression comment would be framed as "allow `assert False`".
 As such, rule names should...
 
 - Highlight the pattern that is being linted against, rather than the preferred alternative.
-  For example, `AssertFalse` guards against `assert False` statements.
+    For example, `AssertFalse` guards against `assert False` statements.
 
 - _Not_ contain instructions on how to fix the violation, which instead belong in the rule
-  documentation and the `autofix_title`.
+    documentation and the `autofix_title`.
 
 - _Not_ contain a redundant prefix, like `Disallow` or `Banned`, which are already implied by the
-  convention.
+    convention.
 
 When re-implementing rules from other linters, we prioritize adhering to this convention over
 preserving the original rule name.
@@ -191,25 +192,25 @@ Ruff's output for each fixture, which you can then commit alongside your changes
 Once you've completed the code for the rule itself, you can define tests with the following steps:
 
 1. Add a Python file to `crates/ruff/resources/test/fixtures/[linter]` that contains the code you
-   want to test. The file name should match the rule name (e.g., `E402.py`), and it should include
+    want to test. The file name should match the rule name (e.g., `E402.py`), and it should include
-   examples of both violations and non-violations.
+    examples of both violations and non-violations.
 
 1. Run Ruff locally against your file and verify the output is as expected. Once you're satisfied
-   with the output (you see the violations you expect, and no others), proceed to the next step.
+    with the output (you see the violations you expect, and no others), proceed to the next step.
-   For example, if you're adding a new rule named `E402`, you would run:
+    For example, if you're adding a new rule named `E402`, you would run:
 
-   ```shell
+    ```shell
-   cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache
+    cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pycodestyle/E402.py --no-cache
-   ```
+    ```
 
 1. Add the test to the relevant `crates/ruff/src/rules/[linter]/mod.rs` file. If you're contributing
-   a rule to a pre-existing set, you should be able to find a similar example to pattern-match
+    a rule to a pre-existing set, you should be able to find a similar example to pattern-match
-   against. If you're adding a new linter, you'll need to create a new `mod.rs` file (see,
+    against. If you're adding a new linter, you'll need to create a new `mod.rs` file (see,
-   e.g., `crates/ruff/src/rules/flake8_bugbear/mod.rs`)
+    e.g., `crates/ruff/src/rules/flake8_bugbear/mod.rs`)
 
 1. Run `cargo test`. Your test will fail, but you'll be prompted to follow-up
-   with `cargo insta review`. Run `cargo insta review`, review and accept the generated snapshot,
+    with `cargo insta review`. Run `cargo insta review`, review and accept the generated snapshot,
-   then commit the snapshot file alongside the rest of your changes.
+    then commit the snapshot file alongside the rest of your changes.
 
 1. Run `cargo test` again to ensure that your test passes.
 
@@ -247,25 +248,25 @@ To preview any changes to the documentation locally:
 
 1. Install MkDocs and Material for MkDocs with:
 
-   ```shell
+    ```shell
-   pip install -r docs/requirements.txt
+    pip install -r docs/requirements.txt
-   ```
+    ```
 
 1. Generate the MkDocs site with:
 
-   ```shell
+    ```shell
-   python scripts/generate_mkdocs.py
+    python scripts/generate_mkdocs.py
-   ```
+    ```
 
 1. Run the development server with:
 
-   ```shell
+    ```shell
-   # For contributors.
+    # For contributors.
-   mkdocs serve -f mkdocs.generated.yml
+    mkdocs serve -f mkdocs.generated.yml
 
-   # For members of the Astral org, which has access to MkDocs Insiders via sponsorship.
+    # For members of the Astral org, which has access to MkDocs Insiders via sponsorship.
-   mkdocs serve -f mkdocs.insiders.yml
+    mkdocs serve -f mkdocs.insiders.yml
-   ```
+    ```
 
 The documentation should then be available locally at
 [http://127.0.0.1:8000/docs/](http://127.0.0.1:8000/docs/).
@@ -286,20 +287,19 @@ even patch releases may contain [non-backwards-compatible changes](https://semve
 1. Create a PR with the version and `BREAKING_CHANGES.md` updated
 1. Merge the PR
 1. Run the release workflow with the version number (without starting `v`) as input. Make sure
-   main has your merged PR as last commit
+    main has your merged PR as last commit
 1. The release workflow will do the following:
-   1. Build all the assets. If this fails (even though we tested in step 4), we haven’t tagged or
+    1. Build all the assets. If this fails (even though we tested in step 4), we haven’t tagged or
-      uploaded anything, you can restart after pushing a fix
+        uploaded anything, you can restart after pushing a fix.
-   1. Upload to pypi
+    1. Upload to PyPI.
-   1. Create and push the git tag (from pyproject.toml). We create the git tag only here
+    1. Create and push the Git tag (as extracted from `pyproject.toml`). We create the Git tag only
-      because we can't change it ([#4468](https://github.com/charliermarsh/ruff/issues/4468)), so
+        after building the wheels and uploading to PyPI, since we can't delete or modify the tag ([#4468](https://github.com/charliermarsh/ruff/issues/4468)).
-      we want to make sure everything up to and including publishing to pypi worked.
+    1. Attach artifacts to draft GitHub release
-   1. Attach artifacts to draft GitHub release
+    1. Trigger downstream repositories. This can fail non-catastrophically, as we can run any
-   1. Trigger downstream repositories. This can fail without causing fallout, it is possible (if
+        downstream jobs manually if needed.
-      inconvenient) to trigger the downstream jobs manually
+1. Create release notes in GitHub UI and promote from draft.
-1. Create release notes in GitHub UI and promote from draft to proper release(<https://github.com/charliermarsh/ruff/releases/new>)
 1. If needed, [update the schemastore](https://github.com/charliermarsh/ruff/blob/main/scripts/update_schemastore.py)
-1. If needed, update ruff-lsp and ruff-vscode
+1. If needed, update the `ruff-lsp` and `ruff-vscode` repositories.
 
 ## Ecosystem CI
 
@@ -452,7 +452,7 @@ You can run the benchmarks with
 cargo benchmark
 ```
 
-#### Benchmark driven Development
+#### Benchmark-driven Development
 
 Ruff uses [Criterion.rs](https://bheisler.github.io/criterion.rs/book/) for benchmarks. You can use
 `--save-baseline=<name>` to store an initial baseline benchmark (e.g. on `main`) and then use
@@ -491,7 +491,7 @@ cargo install critcmp
 #### Tips
 
 - Use `cargo benchmark <filter>` to only run specific benchmarks. For example: `cargo benchmark linter/pydantic`
-  to only run the pydantic tests.
+    to only run the pydantic tests.
 - Use `cargo benchmark --quiet` for a more cleaned up output (without statistical relevance)
 - Use `cargo benchmark --quick` to get faster results (more prone to noise)
 
@@ -550,7 +550,7 @@ cargo instruments -t time --bench linter --profile release-debug -p ruff_benchma
 ```
 
 - `-t`: Specifies what to profile. Useful options are `time` to profile the wall time and `alloc`
-  for profiling the allocations.
+    for profiling the allocations.
 - You may want to pass an additional filter to run a single test file
 
 Otherwise, follow the instructions from the linux section.
@@ -561,12 +561,12 @@ Otherwise, follow the instructions from the linux section.
 utils with it:
 
 - `cargo dev print-ast <file>`: Print the AST of a python file using the
-  [RustPython parser](https://github.com/astral-sh/RustPython-Parser/tree/main/parser) that is
+    [RustPython parser](https://github.com/astral-sh/RustPython-Parser/tree/main/parser) that is
-  mainly used in Ruff. For `if True: pass # comment`, you can see the syntax tree, the byte offsets
+    mainly used in Ruff. For `if True: pass # comment`, you can see the syntax tree, the byte offsets
-  for start and stop of each node and also how the `:` token, the comment and whitespace are not
+    for start and stop of each node and also how the `:` token, the comment and whitespace are not
-  represented anymore:
+    represented anymore:
 
-```text
+````text
 [
     If(
         StmtIf {
@@ -591,7 +591,7 @@ utils with it:
         },
     ),
 ]
-```
+    ```
 
 - `cargo dev print-tokens <file>`: Print the tokens that the AST is built upon. Again for
   `if True: pass # comment`:
@@ -605,11 +605,11 @@ utils with it:
     "# comment",
 ) 23
 23 Newline 24
-```
+````
 
 - `cargo dev print-cst <file>`: Print the CST of a python file using
-  [LibCST](https://github.com/Instagram/LibCST), which is used in addition to the RustPython parser
+    [LibCST](https://github.com/Instagram/LibCST), which is used in addition to the RustPython parser
-  in Ruff. E.g. for `if True: pass # comment` everything including the whitespace is represented:
+    in Ruff. E.g. for `if True: pass # comment` everything including the whitespace is represented:
 
 ```text
 Module {
@@ -675,13 +675,13 @@ Module {
 ```
 
 - `cargo dev generate-all`: Update `ruff.schema.json`, `docs/configuration.md` and `docs/rules`.
-  You can also set `RUFF_UPDATE_SCHEMA=1` to update `ruff.schema.json` during `cargo test`.
+    You can also set `RUFF_UPDATE_SCHEMA=1` to update `ruff.schema.json` during `cargo test`.
 - `cargo dev generate-cli-help`, `cargo dev generate-docs` and `cargo dev generate-json-schema`:
-  Update just `docs/configuration.md`, `docs/rules` and `ruff.schema.json` respectively.
+    Update just `docs/configuration.md`, `docs/rules` and `ruff.schema.json` respectively.
 - `cargo dev generate-options`: Generate a markdown-compatible table of all `pyproject.toml`
-  options. Used for <https://beta.ruff.rs/docs/settings/>
+    options. Used for <https://beta.ruff.rs/docs/settings/>
 - `cargo dev generate-rules-table`: Generate a markdown-compatible table of all rules. Used for <https://beta.ruff.rs/docs/rules/>
 - `cargo dev round-trip <python file or jupyter notebook>`: Read a Python file or Jupyter Notebook,
-  parse it, serialize the parsed representation and write it back. Used to check how good our
+    parse it, serialize the parsed representation and write it back. Used to check how good our
-  representation is so that fixes don't rewrite irrelevant parts of a file.
+    representation is so that fixes don't rewrite irrelevant parts of a file.
 - `cargo dev format_dev`: See ruff_python_formatter README.md

README.md

@@ -32,10 +32,10 @@ An extremely fast Python linter, written in Rust.
 - 🔧 Autofix support, for automatic error correction (e.g., automatically remove unused imports)
 - 📏 Over [500 built-in rules](https://beta.ruff.rs/docs/rules/)
 - ⚖️ [Near-parity](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) with the
-  built-in Flake8 rule set
+    built-in Flake8 rule set
 - 🔌 Native re-implementations of dozens of Flake8 plugins, like flake8-bugbear
 - ⌨️ First-party [editor integrations](https://beta.ruff.rs/docs/editor-integrations/) for
-  [VS Code](https://github.com/astral-sh/ruff-vscode) and [more](https://github.com/astral-sh/ruff-lsp)
+    [VS Code](https://github.com/astral-sh/ruff-vscode) and [more](https://github.com/astral-sh/ruff-lsp)
 - 🌎 Monorepo-friendly, with [hierarchical and cascading configuration](https://beta.ruff.rs/docs/configuration/#pyprojecttoml-discovery)
 
 Ruff aims to be orders of magnitude faster than alternative tools while integrating more
@@ -364,8 +364,8 @@ Ruff is used by a number of major open-source projects and companies, including:
 - [Great Expectations](https://github.com/great-expectations/great_expectations)
 - [HTTPX](https://github.com/encode/httpx)
 - Hugging Face ([Transformers](https://github.com/huggingface/transformers),
-  [Datasets](https://github.com/huggingface/datasets),
+    [Datasets](https://github.com/huggingface/datasets),
-  [Diffusers](https://github.com/huggingface/diffusers))
+    [Diffusers](https://github.com/huggingface/diffusers))
 - [Hatch](https://github.com/pypa/hatch)
 - [Home Assistant](https://github.com/home-assistant/core)
 - ING Bank ([popmon](https://github.com/ing-bank/popmon), [probatus](https://github.com/ing-bank/probatus))
@@ -377,8 +377,8 @@ Ruff is used by a number of major open-source projects and companies, including:
 - [MegaLinter](https://github.com/oxsecurity/megalinter)
 - Meltano ([Meltano CLI](https://github.com/meltano/meltano), [Singer SDK](https://github.com/meltano/sdk))
 - Microsoft ([Semantic Kernel](https://github.com/microsoft/semantic-kernel),
-  [ONNX Runtime](https://github.com/microsoft/onnxruntime),
+    [ONNX Runtime](https://github.com/microsoft/onnxruntime),
-  [LightGBM](https://github.com/microsoft/LightGBM))
+    [LightGBM](https://github.com/microsoft/LightGBM))
 - Modern Treasury ([Python SDK](https://github.com/Modern-Treasury/modern-treasury-python-sdk))
 - Mozilla ([Firefox](https://github.com/mozilla/gecko-dev))
 - [Mypy](https://github.com/python/mypy)

crates/flake8_to_ruff/README.md

@@ -82,12 +82,12 @@ flake8-to-ruff path/to/.flake8 --plugin flake8-builtins --plugin flake8-quotes
 ## Limitations
 
 1. Ruff only supports a subset of the Flake configuration options. `flake8-to-ruff` will warn on and
-   ignore unsupported options in the `.flake8` file (or equivalent). (Similarly, Ruff has a few
+    ignore unsupported options in the `.flake8` file (or equivalent). (Similarly, Ruff has a few
-   configuration options that don't exist in Flake8.)
+    configuration options that don't exist in Flake8.)
 1. Ruff will omit any rule codes that are unimplemented or unsupported by Ruff, including rule
-   codes from unsupported plugins. (See the
+    codes from unsupported plugins. (See the
-   [documentation](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) for the complete
+    [documentation](https://beta.ruff.rs/docs/faq/#how-does-ruff-compare-to-flake8) for the complete
-   list of supported plugins.)
+    list of supported plugins.)
 
 ## License
 

crates/ruff_python_formatter/README.md

@@ -282,7 +282,7 @@ Compared to `ruff check`, `cargo run --bin ruff_dev -- format-dev` has 4 additio
 - `--stability-check`: Format twice (but don't write to disk) and check for differences and crashes
 - `--multi-project`: Treat every subdirectory as a separate project. Useful for ecosystem checks.
 - `--error-file`: Use together with `--multi-project`, this writes all errors (but not status
-  messages) to a file.
+    messages) to a file.
 
 ## The orphan rules and trait structure
 

docs/configuration.md

@@ -106,13 +106,13 @@ formats. Ruff will automatically disable any conflicting rules when `ALL` is ena
 If you're wondering how to configure Ruff, here are some **recommended guidelines**:
 
 - Prefer `select` and `ignore` over `extend-select` and `extend-ignore`, to make your rule set
-  explicit.
+    explicit.
 - Use `ALL` with discretion. Enabling `ALL` will implicitly enable new rules whenever you upgrade.
 - Start with a small set of rules (`select = ["E", "F"]`) and add a category at-a-time. For example,
-  you might consider expanding to `select = ["E", "F", "B"]` to enable the popular flake8-bugbear
+    you might consider expanding to `select = ["E", "F", "B"]` to enable the popular flake8-bugbear
-  extension.
+    extension.
 - By default, Ruff's autofix is aggressive. If you find that it's too aggressive for your liking,
-  consider turning off autofix for specific rules or categories (see [_FAQ_](faq.md#ruff-tried-to-fix-something--but-it-broke-my-code)).
+    consider turning off autofix for specific rules or categories (see [_FAQ_](faq.md#ruff-tried-to-fix-something--but-it-broke-my-code)).
 
 ## Using `ruff.toml`
 
@@ -284,17 +284,17 @@ directory hierarchy is used for every individual file, with all paths in the `py
 There are a few exceptions to these rules:
 
 1. In locating the "closest" `pyproject.toml` file for a given path, Ruff ignores any
-   `pyproject.toml` files that lack a `[tool.ruff]` section.
+    `pyproject.toml` files that lack a `[tool.ruff]` section.
 1. If a configuration file is passed directly via `--config`, those settings are used for across
-   files. Any relative paths in that configuration file (like `exclude` globs or `src` paths) are
+    files. Any relative paths in that configuration file (like `exclude` globs or `src` paths) are
-   resolved relative to the _current working directory_.
+    resolved relative to the _current working directory_.
 1. If no `pyproject.toml` file is found in the filesystem hierarchy, Ruff will fall back to using
-   a default configuration. If a user-specific configuration file exists
+    a default configuration. If a user-specific configuration file exists
-   at `${config_dir}/ruff/pyproject.toml`, that file will be used instead of the default
+    at `${config_dir}/ruff/pyproject.toml`, that file will be used instead of the default
-   configuration, with `${config_dir}` being determined via the [`dirs`](https://docs.rs/dirs/4.0.0/dirs/fn.config_dir.html)
+    configuration, with `${config_dir}` being determined via the [`dirs`](https://docs.rs/dirs/4.0.0/dirs/fn.config_dir.html)
-   crate, and all relative paths being again resolved relative to the _current working directory_.
+    crate, and all relative paths being again resolved relative to the _current working directory_.
 1. Any `pyproject.toml`-supported settings that are provided on the command-line (e.g., via
-   `--select`) will override the settings in _every_ resolved configuration file.
+    `--select`) will override the settings in _every_ resolved configuration file.
 
 Unlike [ESLint](https://eslint.org/docs/latest/user-guide/configuring/configuration-files#cascading-and-hierarchy),
 Ruff does not merge settings across configuration files; instead, the "closest" configuration file
@@ -462,18 +462,18 @@ By default, Ruff exits with the following status codes:
 - `0` if no violations were found, or if all present violations were fixed automatically.
 - `1` if violations were found.
 - `2` if Ruff terminates abnormally due to invalid configuration, invalid CLI options, or an
-  internal error.
+    internal error.
 
 This convention mirrors that of tools like ESLint, Prettier, and RuboCop.
 
 Ruff supports two command-line flags that alter its exit code behavior:
 
 - `--exit-zero` will cause Ruff to exit with a status code of `0` even if violations were found.
-  Note that Ruff will still exit with a status code of `2` if it terminates abnormally.
+    Note that Ruff will still exit with a status code of `2` if it terminates abnormally.
 - `--exit-non-zero-on-fix` will cause Ruff to exit with a status code of `1` if violations were
-  found, _even if_ all such violations were fixed automatically. Note that the use of
+    found, _even if_ all such violations were fixed automatically. Note that the use of
-  `--exit-non-zero-on-fix` can result in a non-zero exit code even if no violations remain after
+    `--exit-non-zero-on-fix` can result in a non-zero exit code even if no violations remain after
-  autofixing.
+    autofixing.
 
 ## Autocompletion
 

docs/faq.md

@@ -94,8 +94,8 @@ There are a few other minor incompatibilities between Ruff and the originating F
 
 - Ruff doesn't implement all the "opinionated" lint rules from flake8-bugbear.
 - Depending on your project structure, Ruff and isort can differ in their detection of first-party
-  code. (This is often solved by modifying the `src` property, e.g., to `src = ["src"]`, if your
+    code. (This is often solved by modifying the `src` property, e.g., to `src = ["src"]`, if your
-  code is nested in a `src` directory.)
+    code is nested in a `src` directory.)
 
 ## How does Ruff compare to Pylint?
 

playground/README.md

@@ -5,7 +5,7 @@ In-browser playground for Ruff. Available [https://play.ruff.rs/](https://play.r
 ## Getting started
 
 - To build the WASM module, run `wasm-pack build ../crates/ruff_wasm --target web --out-dir ../../playground/src/pkg`
-  from the `./playground` directory.
+    from the `./playground` directory.
 - Install TypeScript dependencies with: `npm install`.
 - Start the development server with: `npm run dev`.