Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support tables as keys in setup({ formatters_by_ft }) #627

Closed
wants to merge 4 commits into from

Conversation

drowning-cat
Copy link

@drowning-cat drowning-cat commented Jan 22, 2025

require('conform').setup({
  -- You can use tables as keys to define multiple file types for the same formatter config
  [{ "bash", "csh", "ksh", "sh", "zsh" }] = { "beautysh" },
  -- Simple keys always override tables as keys, regardless of order
  bash = { "shfmt" },
})

There is only one caveat: lua-language-server currently does not support type annotations for table keys.
See LuaLS/lua-language-server#2610 for more details.

@github-actions github-actions bot requested a review from stevearc January 22, 2025 15:48
@drowning-cat drowning-cat changed the title feat: support tables as keys in setup(opts.formatters_by_ft) feat: support tables as keys in setup({ formatters_by_ft }) Jan 22, 2025
Add support for the following syntax:
```lua
require("conform").setup({
  formatters_by_ft = {
    -- Setup function now supports tables as keys for opts.formatters_by_ft
    [{ "sh", "bash", "zsh" }] = { "beautysh" },
  },
})
```
Function `setup()` unmarshals `opts.formatters_by_ft table` and assigns it to `M.formatters_by_ft`.
Values are copied using `vim.deepcopy` to allow further overriding.

This functionality works exclusively within the setup function.
@stevearc
Copy link
Owner

I appreciate the work that went into this, but I'm not interested in adding this syntax to setup. I have intentionally tried to make the interface as simple and stupid as possible, I've actually removed some old features because they complicated the API. It's easier to learn, easier to read, and is a hard guard against scope creep. I've had issues with my other plugins where feature request upon feature request causes the config options to explode. My current stance is that if it's something that can reasonably be done in the end-user config, it should be. Given that this is just a small bit of syntactic sugar to save a few lines, I don't think it's worth adding.

@stevearc stevearc closed this Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants