Currently, there is no direct way to show the output using a unified diff style.
As a workaround, if you are in a git repo directory, the following commands can show that.
$ git commit -am'save'
// Formats files in place.
$ efmt -w
// Show the diff by using `git`.
$ git diff
BTW, I created efmt#6 to track this issue. Thanks for your feedback!
Good job! The output format is pretty nice. The problem I’ve had with all available erlang formatters I’ve seen so far is that they seem to place more focus on making the code uniform than on making it nice to read. At first glance it looks like efmt comes close to my personal style.
Oh, the formatted code in the section is intendedly ugly. The maximum line length option is set to an unrealistically small value (i.e, --print-width=30) to show the differences between efmt and erlfmt in the cases where many line-wrappings should happen.
I’m going to add a note about the above point to README.md later.
Thank you for your comment.
Indeed, the result ( ?CAPTURE_STACKTRACE->) is a point that should be improved in the future version.
However, as far as the semantic meaning of the code is concerned, I think the current result is okay. This is because, AFAIK, Erlang macros are processed token-level (not string-level), and it’s impossible to make a new token by macro expansions (c.f. The BEAM book – 2.3.1. Compiler Pass: The Erlang Preprocessor (epp).
Let me briefly share the current status of efmt.
After the initial release in November last year, the formatter has been continuously being improved (the latest version is v0.12.0).
A lot of bugs have been fixed and the formatting style has been almost stabilized.
So I think now is a good time to try efmt (my colleagues and I heavily use efmt in daily work).
I shall have to stick with my own formatter, then.
I did once try to conduct an experiment on a question relating to
coding style. I was horrified to discover that my 3rd year Comp.Sci.
students claimed to be unable to read 2 pages of code in black and
white print. They also claimed to be unable to find any mistake in
even a short amount of code if they could not step through it in a
debugger.
In the absence of experimental evidence showing that one style
variant is superior to another, the only way to unify styles is
compulsion. Successful code formatters are configurable for a reason.
I think it’s good to keep using your formatter if it satisfies your needs. As efmt is an opinionated formatter, it enforces the formatting style to the users. But fortunately, there are several Erlang formatters and Erlang programmers can select their favorite one (or no formatter).