Format ejabberd source code using efmt

[badlop]

ejabberd 24.06 introduced experimental support for make format using Rebar3 + rebar3_format and support for make indent using Emacs + erlang-mode. Both of them are optional, and applied in small portions of the ejabberd source code.

The corresponding documentation was added to the Docs site, including an explanation to format automatically when running git push

Unfortunately rebar3_format is now marked as "archived", so it is time to look for an active replacement.

Nowadays I have found two erlang source code formatters:

• Silo's efmt, which looks quite close to the existing formatting
• WhatsApp' erlfmt, more popular, but the resulting format is quite different to what we are used

In some cases that none of them achieves an acceptable formatting, we can use emacs indentation.

This PR:

• setups make format to use efmt
• then prepares some existing code to ensure it will get properly formatted or indented
• it formats and indent all the ejabberd source code base (we can consider this a cosmetic commit)
• and finally adds that cosmetic commit in a "git blame ignore file"

Right now this is a proposal. Please comment alternatives, ideas, problems that you found...

[weiss]

and finally adds that cosmetic commit in a "git blame ignore file"

Sounds good.

Personally I'd still be worried about how that might affect other tools. E.g., when I'm wondering what a specific $line of code is supposed to do, I often consult git log -S"$line". For several years, that query kept returning commit 9deb294328bb3f9eb6bd2c0e7cd500732e9b5830 …

[nosnilmot]

I suggest mentioning in the commit message for the "Result of running "make format indent" for the first time" commit how to ignore it:

# These changes can be ignored by `git blame` using:
#   git blame --ignore-revs-file .git-blame-ignore-revs`
# Or configure git to use always this file:
#   git config blame.ignoreRevsFile .git-blame-ignore-revs

(I realise that technically it is not possible at that point because that file is only added in the next commit, but this is the one that will be seen)

[badlop]

when I'm wondering what a specific $line of code is supposed to do, I often consult git log -S"$line". For several years, that query kept returning commit 9deb294 …

Maybe using grep + invert-grep ?

Example:

$ git log -S"spec add_list"
commit a02cff0e780bb735531594c4ece81e8628f79782
Author: Evgeny Khramtsov <[email protected]>
Date:   Fri Jun 14 12:33:26 2019 +0300

    Use new configuration validator

commit 03de853e4fdcf852ae75a86922c08bb1a0950e6d
Author: Evgeny Khramtsov <[email protected]>
Date:   Tue Sep 18 12:53:36 2018 +0300

    Refactor ejabberd_listener

commit 9deb294328bb3f9eb6bd2c0e7cd500732e9b5830
Author: Badlop <[email protected]>
Date:   Thu Mar 14 10:33:02 2013 +0100

    Accumulated patch to binarize and indent code

And now:

$ git log -S"spec add_list" --invert-grep --grep=Accumulated
commit a02cff0e780bb735531594c4ece81e8628f79782
Author: Evgeny Khramtsov <[email protected]>
Date:   Fri Jun 14 12:33:26 2019 +0300

    Use new configuration validator

commit 03de853e4fdcf852ae75a86922c08bb1a0950e6d
Author: Evgeny Khramtsov <[email protected]>
Date:   Tue Sep 18 12:53:36 2018 +0300

    Refactor ejabberd_listener

[weiss]

Maybe using grep + invert-grep ?

Good idea, thanks.