design per-project config and user-config

[sorawee]

And perhaps provide a way to prefer user config but falls back to project config -- or vice versa.

[jackfirth]

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?

[sorawee]

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.