docs: Format Markdown

docs/contributing.md

@@ -12,4 +12,4 @@ There are multiple ways to contribute to this project:
 
 For easy documentation fixes, you can edit a file and send a pull request [directly from the GitHub web interface](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files#editing-files-in-another-users-repository). For more complex fixes or improvements, please read our contributor guide. The guide will show you how to setup a development environment to run tests or serve the documentation locally.
 
-[:fontawesome-solid-helmet-safety: Contributor guide](guide/contributors.md){ .md-button }
+[:fontawesome-solid-helmet-safety: Contributor guide](guide/contributors.md){ .md-button }

docs/downstream-projects.md

@@ -4,7 +4,7 @@ Griffe is used by various projects in the Python ecosystem.
 
 ## griffe2md
 
-[griffe2md](https://mkdocstrings.github.io/griffe2md/) outputs API docs in Markdown. It uses Griffe to load the data, and then use Jinja templates to render documentation in Markdown, just like [mkdocstrings-python](https://mkdocstrings.github.io/python/), but in Markdown instead of HTML. 
+[griffe2md](https://mkdocstrings.github.io/griffe2md/) outputs API docs in Markdown. It uses Griffe to load the data, and then use Jinja templates to render documentation in Markdown, just like [mkdocstrings-python](https://mkdocstrings.github.io/python/), but in Markdown instead of HTML.
 
 ## Griffe TUI
 
@@ -14,7 +14,7 @@ Griffe is used by various projects in the Python ecosystem.
 
 ## quartodoc
 
-[quartodoc](https://machow.github.io/quartodoc/) lets you quickly generate Python package API reference documentation using Markdown and [Quarto](https://quarto.org/). quartodoc is designed as an alternative to [Sphinx](https://www.sphinx-doc.org/en/master/). It uses Griffe to load API data and parse docstrings in order to render HTML documentation, just like [mkdocstrings-python](https://mkdocstrings.github.io/python/), but for Quarto instead of Mkdocs. 
+[quartodoc](https://machow.github.io/quartodoc/) lets you quickly generate Python package API reference documentation using Markdown and [Quarto](https://quarto.org/). quartodoc is designed as an alternative to [Sphinx](https://www.sphinx-doc.org/en/master/). It uses Griffe to load API data and parse docstrings in order to render HTML documentation, just like [mkdocstrings-python](https://mkdocstrings.github.io/python/), but for Quarto instead of Mkdocs.
 
 ## pydanclick
 
@@ -26,4 +26,4 @@ Griffe is used by various projects in the Python ecosystem.
 
 ## Yapper
 
-[Yapper](https://pypi.org/project/yapper/) converts Python docstrings to `astro` files for use by the [Astro](https://astro.build/) static site generator. It uses Griffe to parse Python modules and extracts Numpydoc-style docstrings.
+[Yapper](https://pypi.org/project/yapper/) converts Python docstrings to `astro` files for use by the [Astro](https://astro.build/) static site generator. It uses Griffe to parse Python modules and extracts Numpydoc-style docstrings.

docs/extensions/official/autodocstringstyle.md

@@ -10,4 +10,3 @@
 ---
 
 This extension sets the docstring parser to `auto` for all the docstrings of external packages. Packages are considered "external" when their sources are found in a virtual environment instead of a folder under the current working directory. Setting their docstring style to `auto` is useful if you plan on rendering the docstring of these objects in your own documentation.
-

docs/extensions/official/sphinx.md

@@ -35,4 +35,4 @@ Trailing comments are not supported:
 
 ```python
 module_attr  #: This is not supported.
-```
+```

docs/extensions/official/typingdoc.md

@@ -7,7 +7,7 @@
 
 ---
 
-This extension reads docstrings for parameters, return values and more from type annotation using [`Annotated`][typing.Annotated] and the [`Doc`][typing_extensions.Doc] class suggested in [PEP 727](https://peps.python.org/pep-0727/). Documenting parameters and return values this way makes it possible to completely avoid relying on a particular "docstring style" (Google, Numpydoc, Sphinx, etc.) and just use plain markup in module/classes/function docstrings. Docstrings therefore do not have to be parsed at all. 
+This extension reads docstrings for parameters, return values and more from type annotation using [`Annotated`][typing.Annotated] and the [`Doc`][typing_extensions.Doc] class suggested in [PEP 727](https://peps.python.org/pep-0727/). Documenting parameters and return values this way makes it possible to completely avoid relying on a particular "docstring style" (Google, Numpydoc, Sphinx, etc.) and just use plain markup in module/classes/function docstrings. Docstrings therefore do not have to be parsed at all.
 
 ```python
 from typing import Annotated as An

docs/guide/contributors/architecture.md

@@ -104,7 +104,7 @@ Sources are located in the `src` folder, following the [src-layout](https://pack
 
 Our test suite is located in the `tests` folder. It is located outside of the sources as to not pollute distributions (it would be very wrong to publish a `tests` package as part of our distributions, since this name is extremely common), or worse, the public API. The `tests` folder is however included in our source distributions (`.tar.gz`), alongside most of our metadata and configuration files. Check out `pyproject.toml` to get the full list of files included in our source distributions.
 
-The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `_griffe.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module. 
+The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `_griffe.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module.
 
 ## Program structure
 

docs/guide/contributors/commands.md

@@ -1,4 +1,3 @@
-
 # Management commands
 
 The entry-point to run commands to manage the project is our Python `make` script, located in the `scripts` folder. You can either call it directly with `./scripts/make`, or you can use [direnv](https://direnv.net/) to add the script to your command line path. Once direnv is installed and hooked into your shell, allow it once for this directory with `direnv allow`. Now you can directly call the Python script with `make`. The `Makefile` is just here to provide auto-completion.

docs/guide/contributors/setup.md

@@ -7,19 +7,17 @@ To work on the project, whether to update the code or the documentation, you wil
 The only requirement is that you have [Python](https://www.python.org/) and [uv](https://github.com/astral-sh/uv) installed and available on your command line path.
 
 === ":simple-python: pip"
-
     ```bash
     pip install --user uv
     ```
 
     <div class="result" markdown>
 
     [pip](https://pip.pypa.io/en/stable/) is the main package installer for Python.
-    
+
     </div>
 
 === ":simple-pipx: pipx"
-
     ```bash
     pipx install uv
     ```
@@ -31,7 +29,6 @@ The only requirement is that you have [Python](https://www.python.org/) and [uv]
     </div>
 
 === ":simple-rye: rye"
-
     ```bash
     rye install uv
     ```
@@ -49,7 +46,6 @@ Optionally, we recommend using [direnv](https://direnv.net/), which will add our
 [Fork the repository on GitHub](https://github.com/mkdocstrings/griffe/fork), then clone it locally:
 
 === "GitHub CLI"
-
     ```bash
     gh repo clone griffe
     ```
@@ -61,7 +57,6 @@ Optionally, we recommend using [direnv](https://direnv.net/), which will add our
     </div>
 
 === "Git + SSH"
-
     ```bash
     git clone git@github.com:your-username/griffe
     ```
@@ -73,7 +68,6 @@ Optionally, we recommend using [direnv](https://direnv.net/), which will add our
     </div>
 
 === "Git + HTTPS"
-
     ```bash
     git clone https://github.com/your-username/griffe
     ```

docs/guide/contributors/workflow.md

@@ -9,24 +9,24 @@ The development worklow is rather usual.
 **For a new feature:**
 
 1. create a new branch: `git switch -c feat-summary`
-1. edit the code and the documentation
-1. write new tests
+2. edit the code and the documentation
+3. write new tests
 
 **For a bug fix:**
 
 1. create a new branch: `git switch -c fix-summary`
-1. write tests that fail but are expected to pass once the bug is fixed
-1. run [`make test`][task-test] to make sure the new tests fail
-1. fix the code
+2. write tests that fail but are expected to pass once the bug is fixed
+3. run [`make test`][task-test] to make sure the new tests fail
+4. fix the code
 
 **For a docs update:**
 
 <div class="annotate" markdown>
 
 1. create a new branch: `git switch -c docs-summary`
-1. start the live reloading server: `make docs` (1)
-1. update the documentation
-1. preview changes at http://localhost:8000
+2. start the live reloading server: `make docs` (1)
+3. update the documentation
+4. preview changes at http://localhost:8000
 
 </div>
 
@@ -35,15 +35,15 @@ The development worklow is rather usual.
 **Before committing:**
 
 1. run [`make format`][task-format] to auto-format the code
-1. run [`make check`][task-check] to check everything (fix any warning)
-1. run [`make test`][task-test] to run the tests (fix any issue)
-1. if you updated the documentation or the project dependencies:
+2. run [`make check`][task-check] to check everything (fix any warning)
+3. run [`make test`][task-test] to run the tests (fix any issue)
+4. if you updated the documentation or the project dependencies:
     1. run [`make docs`][task-docs]
-    1. go to http://localhost:8000 and check that everything looks good
+    2. go to http://localhost:8000 and check that everything looks good
 
 Once you are ready to commit, follow our [commit message convention](#commit-message-convention).
 
-NOTE: **Occasional contributors**
+NOTE: **Occasional contributors**  
 If you are unsure about how to fix or ignore a warning, just let the continuous integration fail, and we will help you during review. Don't bother updating the changelog, we will take care of this.
 
 ## Breaking changes and deprecations
@@ -72,7 +72,7 @@ except ImportError:
 
 Check [Yore's docs](https://pawamoy.github.io/yore/), and Yore-comments in our own code base (`git grep -A1 YORE`) to learn how to use it.
 
-NOTE: **Occasional contributors**
+NOTE: **Occasional contributors**  
 If you are unsure about how to deprecate something or mark legacy code, let us do it during review.
 
 ## Commit message convention
@@ -114,11 +114,11 @@ Issue-10: https://github.com/namespace/project/issues/10
 Related-to-PR-namespace/other-project#15: https://github.com/namespace/other-project/pull/15
 ```
 
-These "trailers" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons `:`. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number). 
+These "trailers" must appear at the end of the body, without any blank lines between them. The trailer title can contain any character except colons `:`. We expect a full URI for each trailer, not just GitHub autolinks (for example, full GitHub URLs for commits and issues, not the hash or the #issue-number).
 
 We do not enforce a line length on commit messages summary and body.
 
-NOTE: **Occasional contributors**
+NOTE: **Occasional contributors**  
 If this convention seems unclear to you, just write the message of your choice, and we will rewrite it ourselves before merging.
 
 ## Pull requests guidelines
@@ -144,7 +144,7 @@ And force-push:
 git push -f
 ```
 
-NOTE: **Occasional contributors**
+NOTE: **Occasional contributors**  
 If this seems all too complicated, you can push or force-push each new commit, and we will squash them ourselves if needed, before merging.
 
 ## Release process
@@ -162,4 +162,4 @@ Once the changelog is updated, maintainers should review the new version entry,
 
 Once the changelog is ready, a new release can be made with [`make release`][task-release]. If the version wasn't passed on the command-line with `make release version=x.x.x`, the task will prompt you for it. **Use the same version as the one that was just added to the changelog.** For example if the new version added to the changelog is `7.8.9`, use `make release version=7.8.9`.
 
-The [release task][task-release] will stage the changelog, commit, tag, push, then build distributions and upload them to PyPI.org, and finally deploy the documentation. If any of these steps fail, you can manually run each step with Git commands, then [`make build`][task-build], [`make publish`][task-publish] and [`make docs-deploy`][task-docs-deploy].
+The [release task][task-release] will stage the changelog, commit, tag, push, then build distributions and upload them to PyPI.org, and finally deploy the documentation. If any of these steps fail, you can manually run each step with Git commands, then [`make build`][task-build], [`make publish`][task-publish] and [`make docs-deploy`][task-docs-deploy].

docs/guide/users.md

@@ -8,39 +8,39 @@ The following topics will guide you through the various methods Griffe offers fo
 
 <div class="grid cards" markdown>
 
--   :material-cube-scan:{ .lg .middle } **Loading**
+- :material-cube-scan:{ .lg .middle } **Loading**
 
     ---
 
     Griffe can find packages and modules to scan them statically or dynamically and extract API-related information.
 
     [:octicons-arrow-right-24: Learn how to load data](users/loading.md)
 
--   :material-navigation-variant-outline:{ .lg .middle } **Navigating**
+- :material-navigation-variant-outline:{ .lg .middle } **Navigating**
 
     ---
 
     Griffe exposes the extracted API information into data models, making it easy to navigate your API.
 
     [:octicons-arrow-right-24: Learn how to navigate data](users/navigating.md)
 
--   :material-code-json:{ .lg .middle } **Serializing**
+- :material-code-json:{ .lg .middle } **Serializing**
 
     ---
 
     Griffe can serialize your API data into JSON, for other tools to navigate or manipulate it.
 
     [:octicons-arrow-right-24: Learn how to serialize data](users/serializing.md)
 
--   :material-target:{ .lg .middle } **Checking**
+- :material-target:{ .lg .middle } **Checking**
 
     ---
 
     Griffe can compare snapshots of the same API to find breaking changes.
 
     [:octicons-arrow-right-24: Learn how to detect and handle breaking changes](users/checking.md)
 
--   :material-puzzle-plus:{ .lg .middle } **Extending**
+- :material-puzzle-plus:{ .lg .middle } **Extending**
 
     ---
 
@@ -56,23 +56,23 @@ These topics explore the user side: how to write code to better integrate with G
 
 <div class="grid cards" markdown>
 
--   :material-gift-open:{ .lg .middle } **Public API**
+- :material-gift-open:{ .lg .middle } **Public API**
 
     ---
 
     See our recommendations for exposing public APIs to your users.
 
     [:octicons-arrow-right-24: See our public API recommendations](users/recommendations/public-apis.md)
 
--   :material-star-face:{ .lg .middle } **Python code best practices**
+- :material-star-face:{ .lg .middle } **Python code best practices**
 
     ---
 
     See our best practices for writing Python code.
 
     [:octicons-arrow-right-24: See our best practices](users/recommendations/python-code.md)
 
--   :material-text:{ .lg .middle } **Docstrings**
+- :material-text:{ .lg .middle } **Docstrings**
 
     ---