[erlang-questions] [ANN] erlang-formatter 1.0.0 (go fmt for Erlang)
Tue Aug 30 09:54:26 CEST 2016
Sourcer would have some advantages, yes, but it's still in very early
stages. The goal is to have an AST as compatible as possible with the
standard one, so for the time being it is less important which parser is
used. For formatting syntactical correct files there should be no
My take on this is that the first step is to define what the right way to
format code is, in form of a specification or a test suite to be passed by
the formatter. A big part of this is to decide if formatting should be
"indentation only" or "full rewrite" or both - there are arguments to be
made for each variant. Another one is about how to indent (tabs, spaces,
how many) and how wide the page is (80 characters may feel too narrow for
today's monitors, but sometimes code has to be read/edited on narrow
terminals). Different use cases need different configuration, I'm not sure
if it's possible to have one solution to please everybody.
On Mon, Aug 29, 2016 at 11:41 PM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
> Thanks for sharing the project. My thoughts follow.
> vim-erlang-runtime output is very close to erlang.el, and it
> doesn't suffer from some of the parsing erros of current erlang.el (as
> reported on bugs.erlang.org). vim might be more readily available in
> your CI env, if you want to automatically check for style regressions.
> Also, Bengt's bepp looks useful.
> However, I think Vlad's sourcer might be the best base for an escript
> and plugin, especially because it aims to be forgiving with, say,
> unfinished code. This is very important for use in editors.
>  https://github.com/vim-erlang/vim-erlang-runtime
>  https://github.com/ebengt/erlang_stdin_formatter
>  https://github.com/ebengt/erlang_string_io
>  https://github.com/erlang/sourcer
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions