Open sorawee opened 2 years ago
My experience with code formatters is that it's actually bad when they're customizable per-project and per-user. It prevents the language from having a consistent style across its ecosystem. Example code in different libraries looking wildly different is a problem, for instance.
Racket isn't just one language though: through the #lang
mechanism, it's many different languages. What do you think of putting the #lang
in control of customizing the formatting configuration?
https://github.com/aowens-21/racket-formatting by @aowens-21 and @shhyou attempts to handle that aspect, IIUC. From a quick glance, their library differs from mine in that it consistently uses one style throughout the whole program even though doing so will exceed the column limit, and it doesn't handle comments. I do not know if racket-formatting
attaches the style to binding and uses it hygienically or not. I.e., will overriding a macro locally via let-syntax
change the style locally as well? On the other hand, requiring a macro expansion for a formatter to work also has its own drawback (which is not objectively bad -- it's just a different tradeoff).
The way I imagined fmt
will handle #lang
is that these #lang
will define .fmt.rkt
files for their macros, and in a project's .fmt.rkt
, it can import these #lang
's .fmt.rkt
and invoke them.
While you are totally correct that customization is primarily meant to support new macros (see e.g. https://github.com/sorawee/fmt/blob/master/.fmt.rkt), I also don't want to dictate how the program should be formatted. If some people strongly believe in how something should be formatted, I want to allow them do that. After all, this is in the same spirit as how Racket allows people customizing stuff (like creating their own collection library :D) even though it won't immediately integrate well to the ecosystem.
And perhaps provide a way to prefer user config but falls back to project config -- or vice versa.