Update generated neovim config

config/neovim/store/lazy-plugins/conform.nvim/doc/advanced_topics.md

@@ -22,8 +22,6 @@ The way this "aftermarket" range formatting works is conform will format the ent
 
 ## Injected language formatting (code blocks)
 
-Requires: Neovim 0.9+
-
 Sometimes you may have a file that contains small chunks of code in another language. This is most common for markup formats like markdown and neorg, but can theoretically be present in any filetype (for example, embedded SQL queries in a host language). For files like this, it would be nice to be able to format these code chunks using their language-specific formatters.
 
 The way that conform supports this is via the `injected` formatter. If you run this formatter on a file, it will use treesitter to parse out the blocks in the file that have different languages and runs the formatters for that filetype (configured with `formatters_by_ft`). The formatters are run in parallel, one job for each language block.

config/neovim/store/lazy-plugins/conform.nvim/doc/conform.txt

@@ -288,6 +288,8 @@ FORMATTERS                                                    *conform-formatter
 `cbfmt` - A tool to format codeblocks inside markdown and org documents.
 `clang-format` - Tool to format C/C++/… code according to a set of rules and
                heuristics.
+`cljfmt` - cljfmt is a tool for detecting and fixing formatting errors in
+         Clojure code.
 `cljstyle` - Formatter for Clojure code.
 `cmake_format` - Parse cmake listfiles and format them nicely.
 `codespell` - Check code for common misspellings.
@@ -378,6 +380,7 @@ FORMATTERS                                                    *conform-formatter
 `lua-format` - Code formatter for Lua.
 `markdown-toc` - API and CLI for generating a markdown TOC (table of contents)
                for a README or any markdown files.
+`markdownfmt` - Like gofmt, but for Markdown.
 `markdownlint` - A Node.js style checker and lint tool for Markdown/CommonMark
                files.
 `markdownlint-cli2` - A fast, flexible, configuration-based command-line
@@ -391,8 +394,7 @@ FORMATTERS                                                    *conform-formatter
 `nickel` - Code formatter for the Nickel programming language.
 `nimpretty` - nimpretty is a Nim source code beautifier that follows the
             official style guide.
-`nixfmt` - nixfmt is a formatter for Nix code, intended to apply a uniform
-         style.
+`nixfmt` - The official (but not yet stable) formatter for Nix code.
 `nixpkgs_fmt` - nixpkgs-fmt is a Nix code formatter for nixpkgs.
 `npm-groovy-lint` - Lint, format and auto-fix your Groovy / Jenkinsfile / Gradle
                   files using command line.
@@ -459,6 +461,7 @@ FORMATTERS                                                    *conform-formatter
 `styler` - R formatter and linter.
 `stylish-haskell` - Haskell code prettifier.
 `stylua` - An opinionated code formatter for Lua.
+`superhtml` - HTML Language Server and Templating Language Library.
 `swift_format` - Swift formatter from apple. Requires building from source with
                `swift build`.
 `swiftformat` - SwiftFormat is a code library and command-line tool for
@@ -494,6 +497,10 @@ FORMATTERS                                                    *conform-formatter
 `yew-fmt` - Code formatter for the Yew framework.
 `yq` - YAML/JSON processor
 `zigfmt` - Reformat Zig source into canonical form.
+`ziggy` - A data serialization language for expressing clear API messages,
+        config files, etc.
+`ziggy_schema` - A data serialization language for expressing clear API
+               messages, config files, etc.
 `zprint` - Formatter for Clojure and EDN.
 
 ================================================================================

config/neovim/store/lazy-plugins/conform.nvim/doc/debugging.md

@@ -0,0 +1,94 @@
+# Debugging
+
+When you are experiencing problems with a formatter, this doc is intended to give you the background
+information and tools you need to figure out what is going wrong. It should help you answer
+questions like "why isn't my formatter working?" and "why is my formatter using the wrong format?"
+
+<!-- TOC -->
+
+- [Background](#background)
+- [Tools](#tools)
+- [Testing the formatter](#testing-the-formatter)
+
+<!-- /TOC -->
+
+## Background
+
+How does conform work?
+
+Under the hood, conform is just running a shell command, capturing the output, and replacing the
+buffer contents with that output. There are a few fancy things happening with [minimal format
+diffs](advanced_topics.md#minimal-format-diffs), but in practice there are almost never problems
+with that system so you can mostly ignore it.
+
+Conform runs the formatters using `:help vim.system()`, and does one of two things. Some formatters
+support formatting _from_ stdin and _to_ stdout. For these, we pipe the buffer text to the process
+via stdin, and read the stdout back as the new buffer contents. For formatters that don't support
+stdin/out, we create a temporary file in the same directory, write the buffer to it, run the
+formatter, and read back the modified tempfile as the new buffer contents.
+
+## Tools
+
+Conform has two very useful tools for debugging misbehaving formatters: logging and `:ConformInfo`.
+Try running `:ConformInfo` now; you should see something like the window below:
+
+<img width="1243" alt="Screenshot 2024-08-07 at 10 03 17 PM" src="https://github.com/user-attachments/assets/2dbbc2b7-05c1-4c9f-bb8c-345d039b624c">
+
+This contains a snippet of the log file, the location of the log file in case you need to see more
+logs (you can use `gf` to jump to it), available formatters for the current buffer, and a list of
+all the configured formatters. Each formatter has a status, an error message if there is something
+wrong, a list of filetypes it applies to, and the resolved path to the executable.
+
+This should be enough to fix many issues. Double check to make sure your formatter is `ready` and
+that it is configured to run on the filetype(s) you expect. Also double check the path to the
+executable. If all of those look good, then it's time to make more use of the logs.
+
+The first thing you will want to do is increase the verbosity of the logs. Do this by setting the
+`log_level` option:
+
+```lua
+require("conform").setup({
+  log_level = vim.log.levels.DEBUG,
+})
+```
+
+It is recommended to start with `DEBUG` level. You can also use `TRACE`, which will log the entire
+file input and output to the formatter. This can be helpful in some situations, but takes up a lot
+of visual space and so is not recommended until you need that information specifically.
+
+## Testing the formatter
+
+Once you set the log level, try the format operations again, then open the log file (remember, you
+can find it from `:ConformInfo`). You're looking for the lines that tell you what command is being
+run. It should look like this:
+
+```
+21:50:31[DEBUG] Run command: { "black", "--stdin-filename", "/Users/stevearc/dotfiles/vimplugins/conform.nvim/scripts/generate.py", "--quiet", "-" }
+21:50:31[DEBUG] Run default CWD: /Users/stevearc/dotfiles/vimplugins/conform.nvim
+```
+
+This is logging the lua table that is passed to `vim.system()`. The first thing to do is to take this
+command and run it directly in your shell and see what happens. For formatters using stdin/out, it
+will look like this:
+
+```
+cat path/to/file.py | black --stdin-filename path/to/file.py --quiet -
+```
+
+Note that this will print the entire formatted file to stdout. It will be much easier for you if you
+can come up with a small test file just a couple lines long that reproduces this issue. MAKE SURE
+that you `cd` into the CWD directory from the log lines, as that is the directory that conform will
+run the command from. If your formatter doesn't use stdin/out, do the same thing but omit the `cat`.
+The command in the log line will contain a path to a temporary file. Just replace that with the path
+to the real file:
+
+```
+black --quiet path/to/file.py
+```
+
+**Q:** What is the point of all of this? \
+**A:** We're trying to isolate where the problem is coming from: the formatter, the environment
+configuring the formatter, Neovim, or conform. By confirming that the format command works in the
+shell, we can eliminate some of those possibilities. If the format command _doesn't_ work in the
+shell, you will need to iterate on that until you can find one that works. Please DO NOT file an
+issue on this repo until you have a functioning format command in your shell.

config/neovim/store/lazy-plugins/conform.nvim/doc/recipes.md

@@ -5,7 +5,6 @@
 - [Format command](#format-command)
 - [Autoformat with extra features](#autoformat-with-extra-features)
 - [Command to toggle format-on-save](#command-to-toggle-format-on-save)
-- [Automatically run slow formatters async](#automatically-run-slow-formatters-async)
 - [Lazy loading with lazy.nvim](#lazy-loading-with-lazynvim)
 - [Leave visual mode after range format](#leave-visual-mode-after-range-format)
 - [Run the first available formatter followed by more formatters](#run-the-first-available-formatter-followed-by-more-formatters)
@@ -108,35 +107,6 @@ end, {
 })
 ```
 
-## Automatically run slow formatters async
-
-This snippet will automatically detect which formatters take too long to run synchronously and will run them async on save instead.
-
-```lua
-local slow_format_filetypes = {}
-require("conform").setup({
-  format_on_save = function(bufnr)
-    if slow_format_filetypes[vim.bo[bufnr].filetype] then
-      return
-    end
-    local function on_format(err)
-      if err and err:match("timeout$") then
-        slow_format_filetypes[vim.bo[bufnr].filetype] = true
-      end
-    end
-
-    return { timeout_ms = 200, lsp_format = "fallback" }, on_format
-  end,
-
-  format_after_save = function(bufnr)
-    if not slow_format_filetypes[vim.bo[bufnr].filetype] then
-      return
-    end
-    return { lsp_format = "fallback" }
-  end,
-})
-```
-
 ## Lazy loading with lazy.nvim
 
 Here is the recommended config for lazy-loading using lazy.nvim