style: format with dprint

Because a Prettier update (v3.6.0) came out 7 hours ago, containing
changes that alter the way Markdown is formatted:

- https://prettier.io/blog/2025/06/23/3.6.0#markdown

Notably:

- prettier/prettier#16637

Locally, I'm running prettier with `npx`, so I get those changes
immediately.

In CI, runs are failing:

```
2025-06-23T09:16:20.1272956Z ##[group]Run actionsx/prettier@3d9f7c3
2025-06-23T09:16:20.1273344Z with:
2025-06-23T09:16:20.1273543Z   args: --list-different "**/*.md"
2025-06-23T09:16:20.1274004Z ##[endgroup]
2025-06-23T09:16:20.5373798Z lua/wincent/commandt/README.md
```

- https://github.com/wincent/command-t/actions/runs/15820236003

Given that `actionsx/prettier` was last updated two years ago:

- https://github.com/actionsx/prettier/releases/tag/v3

And there has been a request to bump Prettier to v3.0.3 that has gone
ignored since October 2023:

- actionsx/prettier#117

I am not optimistic that this will be resolved quickly, although I
recognize that I might be pleasantly surprised.

Whatever. Enough idle speculation. I'm using dprint quite happily in
other projects, so let's use it here too.

Author: wincent

.dprint.jsonc

@@ -0,0 +1,11 @@
+{
+  "markdown": {
+    // See: https://github.com/dprint/dprint-plugin-markdown/blob/main/src/configuration/types.rs
+
+  },
+  "includes": ["**/*.md"],
+  "excludes": [],
+  "plugins": [
+    "https://plugins.dprint.dev/markdown-0.18.0.wasm"
+  ]
+}

.github/workflows/prettier.yml .github/workflows/dprint.yml.github/workflows/prettier.yml renamed to .github/workflows/dprint.yml

@@ -1,4 +1,4 @@
-name: prettier
+name: dprint
 
 on:
   push:
@@ -14,6 +14,6 @@ jobs:
     if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name != github.event.pull_request.base.repo.full_name
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-      - uses: actionsx/prettier@3d9f7c3fa44c9cb819e68292a328d7f4384be206 # v3
+      - uses: dprint/check@9cb3a2b17a8e606d37aae341e49df3654933fc23 # v2.3
         with:
-          args: --list-different "**/*.md"
+          dprint-version: latest

ARCHITECTURE.md

@@ -23,32 +23,32 @@ In the following discussion, note that there are a few sets of confusing, overla
 
 ## List-based finder life-cycle
 
-1.  (Optional) User configures a mapping in their personal config (eg. `vim.keymap.set('n', '<Leader>b', '<Plug>(CommandTBuffer)')`)
-2.  (Optional) User uses the mapping, which passes through the built-in `<Plug>` mapping to a command (eg. `vim.keymap.set('n', '<Plug>(CommandTBuffer)', ':CommandTBuffer<CR>', { silent = true })`)
-3.  The command invokes the `commandt.finder` function defined in `init.lua`, passing `'buffer'` as a parameter:
-
-    ```
-    vim.api.nvim_create_user_command(CommandTBuffer, function()
-      require('wincent.commandt').finder('buffer')
-    end, {
-      nargs = 0,
-    })
-    ```
-
-4.  `commandt.finder()` takes two params, a finder `name`, and an optional `directory` (not passed in the case of `:CommandTBuffer`, `:CommandTHelp`, `:CommandTHistory`, `:CommandTJump`, `:CommandTLine`, `:CommandTSearch`, or `:CommandTTag`, but passed in the case of `:CommandTFd`, `:CommandTFind`, `:CommandTGit`, and `:CommandTRipgrep`).
-    1.  It looks up the finder config under the `name` key (`'buffer'`, for example) of the user's settings (obtained via a call to `commandt.options()`, which returns a _copy_ of the user's settings, or falls back to the defaults if there are no explicit user settings).
-    2.  If the config defines an `options` callback, it calls the callback with the existing options so that it has an opportunity to transform those options, and then sanitizes them. This is used by several finders to force the display of dotfiles (ie. by unconditionally setting `always_show_dot_files` to `true`, and `never_show_dot_files` to `false`); specifically, the `'buffer'`, `'help'`, `'history'`, `'jump'`, `'line'`, `'search'`, and `'tag'` finders.
-    3.  If the config defines an `on_directory` callback, it calls the callback with the directory to give it the opportunity to transform the directory. This is used by finders which change their root directory based on the `commandt.traverse` setting; if no directory is provided, and the user settings require it, the callback will attempt to infer an appropriate directory, using the current working directory as a fallback. Finders which use `on_directory` include `'fd'`, `'find'`, `'git'`, and `'rg'`.
-    4.  It prepares an `open` callback with signature `open(item, ex_command)` and assigns it back to the `options` object that will be passed into the `finders.list` or `finders.command` implementation, and also into `ui.show()`. This `open` callback will in turn forward to the `open` implementation specified in the config, if provided, otherwise falling back to `commandt.open(item, ex_command)` which is otherwise known as `sbuffer(buffer, command)` (it's called "smart" because it tries to intelligently pick the right place to open the requested buffer). Finders which specify a custom `'open'` in their config include `'fd'`, `'find'`, `'git'`, and `'rg'`; which all pass in an `on_open(item, ex_command, directory, _options, opener, _context)` implementation which uses the `opener` to open a relativized path (ie. `opener(relativize(directory, item), ex_command)`); note that the `opener` here is actually `commandt.open` (ie. `sbuffer()`). In contrast, the `'help'`, `'history'`, `'line'`, `'search'`, and `'tag'` finders define totally custom open callbacks. Finally, the `'buffer'` and `'jump'` finders define nothing, which means they use the fallback.
-    5.  If the finder config provides a `candidates` field, it obtains the actual list finder and context by passing in the `directory`, `config.candidates`, and `options`. Otherwise, it must contain a `command` field and it obtains a command finder passing in `directory`, `config.command`, `options`, and `name` (the `name` is used to look up finder-specific settings in the `options`).
-    6.  If the finder config provides a `fallback` field set to `true`, it adds the fallback finder to the `finder` object, passing in the original `finder`, `directory`, and `options` (this fallback finder is a lazy wrapper around the built-in file finder, which gets invoked if the primary finder fails.
-    7.  It invokes `ui.show()`, passing in the `finder` and `options`, merging in three additional settings: `name`, `mode` (`mode` is `'virtual'`, `'file'` or `nil`), and an `on_close` callback set to `config.on_close`. Finders which actually specify an `on_close` are `'fd'`, `'find'`, `'rg'`, and the built-in file finders; they all use `popd` for this purpose, to reset to the original working directory in case the user specified a temporary directory as an argument to those finders (the watchman finder doesn't need this as it does not change into a temporary directory even when the user specifies a directory argument).
-5.  `ui.show()` sets some module-level state based on the passed in `finder`, `options.on_close`, and `options.on_open`.
-6.  It calls `MatchListing.new()`, passing in specific options, and then `match_listing:show()`.
-7.  It calls `Prompt.new()`, again passing in specific options, including passing `ui.open` via the `on_open` property, then `prompt:show()`.
-    1. `Prompt.new()` captures various settings, including `on_open` and `mappings`. It creates a window with `Window.new()` and `self._window:show()`, and sets up mappings inside that window with `self._window:map()`. When the user chooses to open a selection via a mapping, the prompt will call the `on_open` callback with either `'edit'`, `'split'`, `'tabedit'`, or `'vsplit'` as an argument.
-8.  The `on_open` callback, which is actually `ui.open(ex_command)` (`ex_command` is `'edit'`, `'split'` etc), calls `close()`, which closes the windows and invokes any `on_close` callback.
-9.  If the UI has an `on_open` callback, it calls it so that it can transform the result. Only the built-in file finder and the watchman finder use this, and they both use it to relativize the result in relation to the `directory`.
+1. (Optional) User configures a mapping in their personal config (eg. `vim.keymap.set('n', '<Leader>b', '<Plug>(CommandTBuffer)')`)
+2. (Optional) User uses the mapping, which passes through the built-in `<Plug>` mapping to a command (eg. `vim.keymap.set('n', '<Plug>(CommandTBuffer)', ':CommandTBuffer<CR>', { silent = true })`)
+3. The command invokes the `commandt.finder` function defined in `init.lua`, passing `'buffer'` as a parameter:
+
+   ```
+   vim.api.nvim_create_user_command(CommandTBuffer, function()
+     require('wincent.commandt').finder('buffer')
+   end, {
+     nargs = 0,
+   })
+   ```
+
+4. `commandt.finder()` takes two params, a finder `name`, and an optional `directory` (not passed in the case of `:CommandTBuffer`, `:CommandTHelp`, `:CommandTHistory`, `:CommandTJump`, `:CommandTLine`, `:CommandTSearch`, or `:CommandTTag`, but passed in the case of `:CommandTFd`, `:CommandTFind`, `:CommandTGit`, and `:CommandTRipgrep`).
+   1. It looks up the finder config under the `name` key (`'buffer'`, for example) of the user's settings (obtained via a call to `commandt.options()`, which returns a _copy_ of the user's settings, or falls back to the defaults if there are no explicit user settings).
+   2. If the config defines an `options` callback, it calls the callback with the existing options so that it has an opportunity to transform those options, and then sanitizes them. This is used by several finders to force the display of dotfiles (ie. by unconditionally setting `always_show_dot_files` to `true`, and `never_show_dot_files` to `false`); specifically, the `'buffer'`, `'help'`, `'history'`, `'jump'`, `'line'`, `'search'`, and `'tag'` finders.
+   3. If the config defines an `on_directory` callback, it calls the callback with the directory to give it the opportunity to transform the directory. This is used by finders which change their root directory based on the `commandt.traverse` setting; if no directory is provided, and the user settings require it, the callback will attempt to infer an appropriate directory, using the current working directory as a fallback. Finders which use `on_directory` include `'fd'`, `'find'`, `'git'`, and `'rg'`.
+   4. It prepares an `open` callback with signature `open(item, ex_command)` and assigns it back to the `options` object that will be passed into the `finders.list` or `finders.command` implementation, and also into `ui.show()`. This `open` callback will in turn forward to the `open` implementation specified in the config, if provided, otherwise falling back to `commandt.open(item, ex_command)` which is otherwise known as `sbuffer(buffer, command)` (it's called "smart" because it tries to intelligently pick the right place to open the requested buffer). Finders which specify a custom `'open'` in their config include `'fd'`, `'find'`, `'git'`, and `'rg'`; which all pass in an `on_open(item, ex_command, directory, _options, opener, _context)` implementation which uses the `opener` to open a relativized path (ie. `opener(relativize(directory, item), ex_command)`); note that the `opener` here is actually `commandt.open` (ie. `sbuffer()`). In contrast, the `'help'`, `'history'`, `'line'`, `'search'`, and `'tag'` finders define totally custom open callbacks. Finally, the `'buffer'` and `'jump'` finders define nothing, which means they use the fallback.
+   5. If the finder config provides a `candidates` field, it obtains the actual list finder and context by passing in the `directory`, `config.candidates`, and `options`. Otherwise, it must contain a `command` field and it obtains a command finder passing in `directory`, `config.command`, `options`, and `name` (the `name` is used to look up finder-specific settings in the `options`).
+   6. If the finder config provides a `fallback` field set to `true`, it adds the fallback finder to the `finder` object, passing in the original `finder`, `directory`, and `options` (this fallback finder is a lazy wrapper around the built-in file finder, which gets invoked if the primary finder fails.
+   7. It invokes `ui.show()`, passing in the `finder` and `options`, merging in three additional settings: `name`, `mode` (`mode` is `'virtual'`, `'file'` or `nil`), and an `on_close` callback set to `config.on_close`. Finders which actually specify an `on_close` are `'fd'`, `'find'`, `'rg'`, and the built-in file finders; they all use `popd` for this purpose, to reset to the original working directory in case the user specified a temporary directory as an argument to those finders (the watchman finder doesn't need this as it does not change into a temporary directory even when the user specifies a directory argument).
+5. `ui.show()` sets some module-level state based on the passed in `finder`, `options.on_close`, and `options.on_open`.
+6. It calls `MatchListing.new()`, passing in specific options, and then `match_listing:show()`.
+7. It calls `Prompt.new()`, again passing in specific options, including passing `ui.open` via the `on_open` property, then `prompt:show()`.
+   1. `Prompt.new()` captures various settings, including `on_open` and `mappings`. It creates a window with `Window.new()` and `self._window:show()`, and sets up mappings inside that window with `self._window:map()`. When the user chooses to open a selection via a mapping, the prompt will call the `on_open` callback with either `'edit'`, `'split'`, `'tabedit'`, or `'vsplit'` as an argument.
+8. The `on_open` callback, which is actually `ui.open(ex_command)` (`ex_command` is `'edit'`, `'split'` etc), calls `close()`, which closes the windows and invokes any `on_close` callback.
+9. If the UI has an `on_open` callback, it calls it so that it can transform the result. Only the built-in file finder and the watchman finder use this, and they both use it to relativize the result in relation to the `directory`.
 10. The thing that actually opens the result is called with `vim.defer_fn()`, to give autocommands a chance to run. The called function is `current_finder.open(result, ex_command)`. Recall from the above that finders like `'fd'` pass in an `options.open` that relativizes the path and uses the `opener` (`commandt.open()`) to do a "smart open". Finders like the `'help'` finder define a custom callback. Finders like `'buffer'` and `'jump'` define no `on_open`, so use the default.
 
 ## Command-based finder life-cycle

CONTRIBUTING.md

@@ -185,8 +185,7 @@ cd FlameGraph
 ./flamegraph.pl dtrace.collapsed > dtrace.svg
 ```
 
-[^tricks]:
-    Tricks which didn't work included running from inside `lua/wincent/commandt/lib` (where the dSYM bundle is), and moving the dSYM bundle up to the root and running from there.
+[^tricks]: Tricks which didn't work included running from inside `lua/wincent/commandt/lib` (where the dSYM bundle is), and moving the dSYM bundle up to the root and running from there.
 
     The probable reason why automatic symbol discovery doesn't work is the UUID mismatch between the library and the process that `dtrace` is executing:
 

bin/check-format

@@ -12,7 +12,7 @@ EXIT=0
 
 stylua --check . || EXIT=1
 
-npx -y prettier --list-different "**/*.md" || EXIT=1
+npx -y dprint check "**/*.md" || EXIT=1
 
 set -o pipefail
 

bin/format

@@ -12,7 +12,7 @@ cd "$REPO_ROOT"
 
 stylua .
 
-npx -y prettier --write "**/*.md"
+npx -y dprint fmt "**/*.md"
 
 # -i = inplace edit
 find . -iname '*.[ch]' | xargs clang-format -i