Should we discontinue this project due to lack of support for formatting code in OTP27?

[elbrujohalcon]

Check what I posted in #359, which can be summarized as:

OTP itself doesn't provide support for knowing how a sigil or a heredoc string were written originally. In other words, when parsed with epp_dodger (or ktn_dodger, FWIW), ~b"abc" is exactly the same as <<"abc"/utf8>> and "this\nstring" is the same as…

"""
this
string
"""

Considering that information, I'm inclined to discontinue this project because it will be pretty much useless for code written for OTP27+ since it will screw up all -doc, -moduledoc, and sigils.

In theory… we could try to patch ktn_dodger to provide the missing information but that module is already a large hack on top of what epp_dodger (arguably a hack itself) does. It will be nasty, to say the least.

So, here is my question, folks!

[NelsonVides]

I don't know how the internals of this codebase work but, my first thought is, how did erlfmt solve this problem? Maybe there's a trick to learn there?

I can't contribute much more than this because I'm away on holidays, just a quick thought right now.

[elbrujohalcon]

They created their own parser.

[bormilan]

I believe this project has great potential, and I would love to be involved, which is why I voted to continue working on it. However, if it poses too many challenges, it might be better to let it go. I lack the knowledge and experience to evaluate the amount of work required, but I genuinely think this project is worth the time investment.

I am also uncertain if there are alternative options for Erlang developers seeking a fully customizable auto-formatter.

In conclusion, I don't know how many people are available to contribute to this project or the exact scope of the needed improvements. However, if this partnership leads to a positive outcome, I support moving forward.