The initial fmt "synthesis" plan

[oubiwann]

General problem statement: LFE has need of a CLI-capable formatter, as its only blessed formatting tool is the indentation provided by lfe-mode in Emacs (which is wonderful, and all we have needed for a decade+).

There is an open question about the state of LFE source code formatting here:

• Is there any tool for formatting code? lfe#500

I had produced a quick solution available for use as part of rebar3_lfe, but it aggressively reformatted to fill 80 columns before wrapping, and have been working on a better version since then.

However, I have simultaneously discovered Racket's raco fmt based upon a 2023 paper (pretty-expressive); have discovered other literature that also utilities the maths of abstract algebra to solve formatting problems, and have seriously rabbit-holed. I'm going to pull all of that toegether here, and I have plans to unite all code explorations here in this repo as different versions.

Version + tag plan

Git tags are labels on commits. The version line is the unified narrative of the formatter project's release readiness — Fezzik is done (Arc A7 complete) so it ships first; pe is still mid-flight (arc2/slice2) so it ships at 0.5.0; pc (pretty-canny) later at 0.6.0.

ver	what it marks	tagged commit	complete?	migrated?	hex?
0.1.0	first usable brute impl	imported A6·S0 commit (was 41fcc55)	✅	✅	no
0.2.0	better brute impl	imported latest pre-rename r3lfe_formatter commit	✅	✅	no
0.3.0	namespace rename → lfmt_fezzik*	the rename commit (made in fmt)	✅	✅	no
0.4.0	split into lfmt_fezzik_*	the split commit (made in fmt)	✅	NA	yes — first hex release
0.5.0	lfmt_pe release	future	🚧	NA	yes
0.6.0	lfmt_pc release	future	🚧	NA	yes

A wrinkle about the retroactive tags: after filter-repo, the imported 0.1.0/0.2.0 commits contain only the engine files — no app.src, no rebar.config — so they are source-history markers, not buildable releases. That's fine and intended; the first buildable, publishable tag is 0.4.0. (If you ever want 0.1.0/0.2.0 to be buildable, you'd tag post-merge states in fmt instead — not worth it.)

Notes

• v0.5.0 - An LFE pretty-expressive implementation; introduced a Rust oracle (using pretty-expressive) for verification
• v0.6.0 - A research project that not only makes computational optimisations on pretty-expressive, but also does some convex algebra tricks; tentatively called pretty-canny and while almost entirely research-only (with a few very minor benchmarks), the post-PoC goal is to co-support it with pretty-expressive and offer both in the same library
• Of interest: The elegance Rust library and related blog post