languages/formatters: allow multiple formatters

[horriblename]

Allow multiple formatters in vim.languages.<lang>.format.type, deprecates use of non list type

Also deprecates non-list values in vim.languages.*.lsp.server

Sanity Checking

• I have updated the changelog as per my changes
• I have tested, and self-reviewed my code
• My changes fit guidelines found in hacking nvf
• Style and consistency
  • I ran Alejandra to format my code (nix fmt)
  • My code conforms to the editorconfig configuration of the project
  • My changes are consistent with the rest of the codebase
• If new changes are particularly complex:
  • My code includes comments in particularly complex areas
  • I have added a section in the manual
  • (For breaking changes) I have included a migration guide
• Package(s) built:
  • .#nix (default package)
  • .#maximal
  • .#docs-html (manual, must build)
  • .#docs-linkcheck (optional, please build if adding links)
• Tested on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin

---

Add a 👍 reaction to pull requests you find important.

[github-actions]

🚀 Live preview deployed from 3e48f13

View it here:

Debug Information

Triggered by: horriblename

HEAD at: python-multi-formatter

Reruns: 1495

[NotAShelf]

I think this will be easier if you cover all at once, because we will need to cover it before 0.8 anyway.

[horriblename]

aight bet

[NotAShelf]

Thank you for the good work.

I'm afraid I'll have to nit this a little, because I think we're inadvertently introducing some technical debt that will end up biting us in the ass later down the line.

1. The functions with "deprecated" in their names are bothering me a little. Are we doing to get rid of those? If so, why not do that now since 0.8 is the big bad breaking change.
2. The removal of "format" sections is not really good practice imo. We should strive to provide predictable and consistent APIs for the users, and I think removing two options does the opposite of contributing to this goal
3. I left a few comments about unpacked sets, statix warns you about those and I'd rather get rid of them while we're already working on it.

[NotAShelf]

I think removing format options introduces an annoying, backwards-incompatible breakage that the users will not appreciate.

We should instead find a way to minimize the surface, e.g., how much users are affected by the "broken for a long time" section. We could warn them, or we could provide a stub that doesn't format anything but simply warn the user.

[horriblename]

I'm gonna add back biome but I don't consider removing prettier and prettierd a breaking change because that thing never worked, can't break user's workflow when the workflow never worked.

nevertheless, I'll look into packaging prettier-plugin-astro and -svelte, if it's not a pain in the neck I'll add them back in.

_{fuck all these frameworks holy fuck how hard is it to write your own fucking formatter you already have to parse the whole thing just print it back out nicely goddammit}

[horriblename]

Added back in biome and prettier, removed prettierd because trying to support it is pure insanity

[horriblename]

for now trying to use prettierd falls back to prettier in astro and svelte

[horriblename]

The functions with "deprecated" in their names are bothering me a little. Are we doing to get rid of those? If so, why not do that now since 0.8 is the big bad breaking change.

yea we're getting rid of them in the future, I just put up a little warning for now if you use the old syntax and convert it for you, just cuz I can and also cuz I hate breaking changes that don't say anything useful in logs/warning