Just wanted to close the loop on this thread - after discussing with José in Phoenix LiveView PR: https://github.com/phoenixframework/phoenix_live_view/pull/3654 I'll be changing Hologram's template sigil from ~H to ~HOLO. While I see sigils as regular functions that different libraries should be able to use independently (like sigil_H/2), and have some reservations about letting LLMs influence architecture decisions, the practical benefits of distinct sigils make sense.
On Wednesday, January 29, 2025 at 11:29:22 PM UTC+1 José Valim wrote: > 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 <ba...@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-co...@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/8e05221e-810c-47c4-9214-2770f80ef114n%40googlegroups.com.
