All options you pass at the root are already received by the formatter. In this case though, I would really recommend picking another sigil though. Two sigils of the same name cannot coexist and you would have have to import each accordingly.
*José Valimhttps://dashbit.co/ <https://dashbit.co/>* On Wed, Jan 29, 2025 at 23:12 Bart Blast <b...@bartblast.com> wrote: > Related Phoenix.LiveView formatter pull request: > https://github.com/phoenixframework/phoenix_live_view/pull/3654 > > On Wednesday, January 29, 2025 at 11:02:31 PM UTC+1 Bart Blast wrote: > >> *Problem * >> >> Currently, formatter plugins cannot receive custom options. This >> limitation becomes problematic in scenarios where plugins need >> configuration to determine their scope or behavior. >> *Real-world Example * >> >> The Phoenix LiveView formatter plugin formats all ~H sigils in the >> codebase. However, ~H sigils are general-purpose and can be used by any >> library (e.g., Hologram uses them for its own purposes). This leads to >> issues: >> >> - When Hologram codebase is formatted, the LiveView formatter raises >> errors because it incorrectly attempts to parse Hologram's ~H sigils as >> HEEx templates >> - Currently, there's no way to tell the LiveView formatter which >> paths should be formatted and which should be ignored >> >> *Proposal * >> >> Allow specifying custom options for formatter plugins in .formatter.exs: >> >> Current syntax: >> [ >> # ... >> formatters: [MyLib1.Formatter, MyLib2.Formatter], >> # ... >> ] >> >> Proposed syntax: >> [ >> # ... >> formatters: [MyLib1.Formatter, {MyLib2.Formatter, a: 1, b: 2}], >> # ... >> ] >> >> *Benefits * >> >> 1. Plugins can receive configuration to customize their behavior >> 2. Solves the LiveView vs Hologram formatter collision by allowing >> users to specify which paths should be formatted by which plugin >> 3. More flexible and configurable formatting system overall >> >> *Implementation Notes * >> >> - The formatter would pass these options to the plugin's formatting >> functions >> - Plugins not requiring options can still be specified using the >> current syntax >> - Backward compatible change - existing formatter configurations >> would continue to work >> >> -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/elixir-lang-core/504b9140-c09a-4937-a330-4587e5965efcn%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/504b9140-c09a-4937-a330-4587e5965efcn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JME2nJZgzJGrdiZdnAQqW%3DratRT9AssfKT1Wt2eY7-RA%40mail.gmail.com.
