Support more code fence formatter plugins

[nzoschke]

Can we make it so this formatter can be configured to call out to any plugin by code fence hint?

Right now it requires an explicit map in the plugin code. It would be nice to get these PRs in there:

• fix: format JSONC code blocks as such, not JSON #144
• feat: support formatting XML code blocks #143
• feat: support formatting Dockerfile code blocks #142

Then I am working on a plugin for a far less popular language https://cuelang.org/.

It would be great if there was a way to experiment and support all languages through config versus having to release a new version of the markdown plugin.

[dsherret]

@nzoschke if you'd like to submit a pr for it, go for it! I merged all those prs and will do a release in a bit.

[dsherret]

The hard part is there needs to be a mapping configured for code fence tag to extension. So probably there would need to be some config where that could be defined.

[nzoschke]

Nice thanks for merging those other PRs! As a fallback I can open a similar one for my plugin someday.

But since you're into the idea I'll take a crack at a configuration mapping soon too.

[dsherret]

Yup. Thanks!

[nzoschke]

A design sketch

dprint config:

{
  "markdown": {
    "tags": {
      "cue": "cue",
      "cuelang": "cue"
    }
  },
  "plugins": [
    "https://plugins.dprint.dev/typescript-0.95.11.wasm",
    "https://plugins.dprint.dev/json-0.20.0.wasm",
    "https://plugins.dprint.dev/markdown-0.19.0.wasm",
    "https://plugins.dprint.dev/cue-0.1.0.wasm"
  ]
}

Main design question is the config key and format. The code is tag_to_extension and "typescript" | "ts" => Some("ts") which is where my sketch is from.

[dsherret]

That looks good. Not sure about the name "tags", but we can decide on something before merging.