style: Apply deno fmt to fix formatting issues

- Fix trailing whitespace in markdown files
- Ensure consistent line breaks
- Format JSON code blocks properly

Author: lambdalisue

src/getting-started/README.md

@@ -8,7 +8,8 @@ Let's start by creating a simple plugin to learn how to develop Denops plugins.
 
 ## Create a Plugin
 
-Create a directory named `denops-getting-started` in your home directory with the following structure:
+Create a directory named `denops-getting-started` in your home directory with
+the following structure:
 
 ```
 $HOME
@@ -33,10 +34,11 @@ First, create a root `deno.jsonc` file for development configuration:
 > [!TIP]
 >
 > The root `deno.jsonc` is for development purposes. It enables commands like
-> `deno fmt`, `deno lint`, and `deno test` to work from your project root.
-> You can add development-specific settings here without affecting runtime.
+> `deno fmt`, `deno lint`, and `deno test` to work from your project root. You
+> can add development-specific settings here without affecting runtime.
 
-Then, create a `deno.jsonc` file inside `denops/denops-getting-started/` for runtime dependencies:
+Then, create a `deno.jsonc` file inside `denops/denops-getting-started/` for
+runtime dependencies:
 
 ```json,title=denops/denops-getting-started/deno.jsonc
 {
@@ -48,11 +50,12 @@ Then, create a `deno.jsonc` file inside `denops/denops-getting-started/` for run
 
 > [!NOTE]
 >
-> Import map support (both `deno.json` imports and `import_map.json`) requires 
+> Import map support (both `deno.json` imports and `import_map.json`) requires
 > Denops v8.0.0 or later. Denops supports multiple configuration formats:
+>
 > - `deno.json` and `deno.jsonc` (recommended)
 > - `import_map.json` and `import_map.jsonc` (also supported)
-> 
+>
 > We use `deno.jsonc` in examples as it allows comments and requires less
 > verbose configuration than import maps.
 
@@ -73,9 +76,11 @@ export const main: Entrypoint = (denops) => {
 > [!IMPORTANT]
 >
 > We separate development configuration from runtime dependencies:
-> - **Root `deno.jsonc`**: Contains workspace configuration for development tools
+>
+> - **Root `deno.jsonc`**: Contains workspace configuration for development
+>   tools
 > - **Plugin `deno.jsonc`**: Contains import maps for runtime dependencies
-> 
+>
 > This separation is crucial because the root `deno.jsonc` is only used during
 > development, while the plugin-specific `deno.jsonc` is what Denops uses at
 > runtime to resolve imports.

src/getting-started/explanation.md

@@ -242,19 +242,28 @@ auto-completion and type checking provided by LSP (Language Server Protocol).
 > Denops v8.0.0 or later. For older versions, use direct URL imports in your
 > TypeScript files.
 
-While the examples above use direct URL imports, the recommended approach for Denops plugins is to separate development configuration from runtime dependencies:
-
-- **Development configuration**: The root `deno.jsonc` with workspace settings enables development tools (`deno lint`, `deno fmt`, etc.) to work from the project root
-- **Runtime dependencies**: The plugin-specific `deno.jsonc` contains only the import map needed at runtime
-- **No conflicts**: Since each Denops plugin has a unique directory under `denops/`, their configuration files never conflict when installed
-- **Clean separation**: Development tools configuration stays in the repository root, while runtime dependencies are isolated per plugin
-- **Flexible format**: Both `deno.json` and `deno.jsonc` are supported, but `deno.jsonc` is recommended for its comment support
+While the examples above use direct URL imports, the recommended approach for
+Denops plugins is to separate development configuration from runtime
+dependencies:
+
+- **Development configuration**: The root `deno.jsonc` with workspace settings
+  enables development tools (`deno lint`, `deno fmt`, etc.) to work from the
+  project root
+- **Runtime dependencies**: The plugin-specific `deno.jsonc` contains only the
+  import map needed at runtime
+- **No conflicts**: Since each Denops plugin has a unique directory under
+  `denops/`, their configuration files never conflict when installed
+- **Clean separation**: Development tools configuration stays in the repository
+  root, while runtime dependencies are isolated per plugin
+- **Flexible format**: Both `deno.json` and `deno.jsonc` are supported, but
+  `deno.jsonc` is recommended for its comment support
 
 ### Separation of Development and Runtime Configuration
 
 The workspace pattern serves two distinct purposes:
 
-1. **Development Time**: The root `deno.jsonc` enables development commands to work properly:
+1. **Development Time**: The root `deno.jsonc` enables development commands to
+   work properly:
    ```json
    {
      "workspace": [
@@ -271,7 +280,8 @@ The workspace pattern serves two distinct purposes:
    }
    ```
 
-2. **Runtime**: The plugin's `deno.jsonc` contains only what's needed for execution:
+2. **Runtime**: The plugin's `deno.jsonc` contains only what's needed for
+   execution:
    ```json
    {
      "imports": {
@@ -282,7 +292,9 @@ The workspace pattern serves two distinct purposes:
 
 ### Why This Separation Matters
 
-When Vim/Neovim loads plugins, it merges all plugin directories into the runtime path. If runtime dependencies were in the root configuration file, they would conflict:
+When Vim/Neovim loads plugins, it merges all plugin directories into the runtime
+path. If runtime dependencies were in the root configuration file, they would
+conflict:
 
 ```
 # After installation, plugins are merged:
@@ -338,13 +350,15 @@ When Vim/Neovim loads plugins, it merges all plugin directories into the runtime
 ```
 
 This separation ensures:
+
 - Development tools like `deno fmt` and `deno lint` work from your project root
 - Runtime dependencies are properly resolved when the plugin is installed
 - No conflicts occur between multiple installed Denops plugins
 
 ### Alternative: Using import_map.json(c)
 
-While the examples above use `deno.jsonc`, Denops also supports `import_map.json(c)` files in the plugin directory:
+While the examples above use `deno.jsonc`, Denops also supports
+`import_map.json(c)` files in the plugin directory:
 
 ```
 denops/your-plugin-name/
@@ -354,12 +368,13 @@ denops/your-plugin-name/
 
 However, there are important differences:
 
-1. **Import Maps Standard** (import_map.json) requires both entries for submodules:
+1. **Import Maps Standard** (import_map.json) requires both entries for
+   submodules:
    ```json
    {
      "imports": {
        "@denops/std": "jsr:@denops/std@^7.0.0",
-       "@denops/std/": "jsr:@denops/std@^7.0.0/"  // Required for submodules
+       "@denops/std/": "jsr:@denops/std@^7.0.0/" // Required for submodules
      }
    }
    ```
@@ -368,14 +383,15 @@ However, there are important differences:
    ```json
    {
      "imports": {
-       "@denops/std": "jsr:@denops/std@^7.0.0"  // Handles both cases
+       "@denops/std": "jsr:@denops/std@^7.0.0" // Handles both cases
      }
    }
    ```
 
 > [!IMPORTANT]
 >
 > We recommend using `deno.jsonc` over `import_map.jsonc` because:
+>
 > - It requires less verbose configuration
 > - It's the standard Deno configuration format
 > - It supports additional configuration options beyond imports
@@ -422,7 +438,9 @@ import { Maze } from "maze_generator";
 
 ### Import Map Structure
 
-The `deno.json` file in your Denops plugin directory should contain all the dependencies your plugin needs. This keeps dependency management isolated to each plugin while avoiding conflicts in the merged runtime directory.
+The `deno.json` file in your Denops plugin directory should contain all the
+dependencies your plugin needs. This keeps dependency management isolated to
+each plugin while avoiding conflicts in the merged runtime directory.
 
 For example, if your plugin uses additional npm packages:
 

src/tutorial/helloworld/adding-an-api.md

@@ -3,7 +3,8 @@
 In the previous section, we created a minimal Denops plugin. In this section, we
 will enhance the plugin by adding an API.
 
-First, update your `denops/denops-helloworld/deno.jsonc` to include the unknownutil dependency:
+First, update your `denops/denops-helloworld/deno.jsonc` to include the
+unknownutil dependency:
 
 ```json,title=denops/denops-helloworld/deno.jsonc
 {

src/tutorial/helloworld/creating-a-minimal-denops-plugin.md

@@ -16,7 +16,7 @@ the corresponding file as a TypeScript module and calls the function named
 
 [denops.vim]: https://github.com/vim-denops/denops.vim
 
-Let's first create the workspace configuration and directory structure for 
+Let's first create the workspace configuration and directory structure for
 `denops-helloworld`. The directory tree will be as follows:
 
 ```

src/tutorial/maze/creating-applicative-plugin.md

@@ -28,7 +28,8 @@ augroup denops_maze
 augroup END
 ```
 
-Then, update your `denops/denops-maze/deno.jsonc` to include the unknownutil dependency:
+Then, update your `denops/denops-maze/deno.jsonc` to include the unknownutil
+dependency:
 
 ```json,title=denops/denops-maze/deno.jsonc
 {

src/tutorial/maze/utilizing-third-party-library.md

@@ -64,7 +64,8 @@ Then, create the `denops/denops-maze/deno.jsonc` file for runtime dependencies:
 >
 > We include both `@denops/std` and `@denops/std/` in the import map. The first
 > one allows imports like `import type { Entrypoint } from "@denops/std"`, while
-> the second enables submodule imports like `import * as buffer from "@denops/std/buffer"`.
+> the second enables submodule imports like
+> `import * as buffer from "@denops/std/buffer"`.
 
 The content of the `denops/denops-maze/main.ts` file will be: