[erlang-questions] Indentation of multiline strings
Fri Feb 7 16:27:43 CET 2014
On Fri, Feb 7, 2014 at 9:09 AM, Vlad Dumitrescu <> wrote:
> Hi Steve,
> On Fri, Feb 7, 2014 at 2:38 PM, Steve Vinoski <> wrote:
> > On Fri, Feb 7, 2014 at 3:29 AM, Vlad Dumitrescu <>
> >> What is the official position regarding indenting multiline strings?
> >> If the emacs indentation code is broken, it means one can't reindent
> >> files without risking trouble...
> > You're trying to automate something that until now has not been
> > at least not in public view to the best of my knowledge, so you're going
> > hit problems like these. From what I've seen, users currently tend to
> > these problem areas manually so that they appear the way they would if
> > erlang-mode got them right.
> Well, yes, I am trying to provide tools that will help people focus on
> what is important instead of having to remember which files can be
> reindented and which one can't (for example). Tools that work as
> expected, without nasty effects that may only be noticed later. The
> kind of tools that Joe and others asked for. If people are happy doing
> this kind of manual work, please let me know so that I can work on
> something more useful, but please don't say later that "the tools are
It's not for me to decide whether people in general are happy or not with
the current state of affairs. Rather, I'm just trying to answer your
questions given my understanding of the current state of the emacs
erlang-mode indentation capabilities, which I think is more informed than
most, and also explain my own approach to patching Erlang/OTP code. My
replies contain no explicit or implicit criticism of your work.
In order to be able to do that, there has to be a specification, so
> that people know what to expect. In this particular case, that
> specification would be an official indentation and formatting guide,
> that in practice would become the standard way of doing it. The
> current situation is that the emacs implementation is that
> specification (for indenting), except that it has some cases where it
> doesn't work. There are also some Erlang pretty printers
> (erl_prettypr, erl_tidy), but these have their problems too as they
> rely on the code to be parsable and I don't know how much their output
> matches that of the emacs indenter and with each other.
Understood -- this is just another way of saying what I said originally,
which is that "you're trying to automate something that until now has not
> Wouldn't it be nice if there was an implementation independent
> specification? I am willing to put one together. This will make it
> much easier to make sure that the erlang support for different editors
> and IDEs is formatting the code in the same way and we can take the
> opportunity to specify (and maybe even implement) all the edge cases
> that emacs gets wrong.
Yes, I understand the goal, and I provided my answers to your previous
questions based on that understanding.
I think it would be beneficial if we had a standard Erlang indentation tool
independent of emacs, for exactly the reasons you mention. I'm quite happy
to help as much as I can to achieve that goal. For me personally, it would
relieve me of having to manually work around the incorrect indentation that
users of editors other than emacs sometimes put in the sources (hi haters).
First, let's assume there's general agreement in the community that emacs
erlang-mode is the de facto standard for erlang code formatting, and is
thus the starting point for developing a formatting specification. I
believe you're basing your work on this assumption, Vlad, and if so I agree
with that approach, but if not please correct me. Some might object to
using erlang-mode as the starting point on the basis that other editors
sometimes have a hard time formatting code the same way erlang-mode does,
but I believe most of the OTP team and most of the Erlang community uses
emacs and erlang-mode, so I view it as the most practical starting point.
To create a formatting specification, I recommend that if you haven't done
so already, start collecting cases like the multiline string and binary
cases where erlang-mode fails, and report them as bugs against erlang-mode.
Obviously this applies to anyone who wishes to help.
To resolve those bugs, we may need to form a small group that can decide
how erlang-mode should format the problematic cases. A good choice for
volunteers here are the primary erlang-mode maintainer and some willing
subset of those who have recently contributed code and patches to
erlang-mode. As one of those people, I'm willing to help with that, and
also willing to help resolve the bugs in erlang-mode so it conforms to the
specification you're putting together.
I assume that during this effort someone -- probably you Vlad, but I know
of other parties also interested -- would be writing a new tool that also
conforms to the formatting specification. Having such a tool would give us
at least two independent implementations of the spec.
The resulting spec would then become part of Erlang/OTP and would be
administered and maintained by the OTP team, same as the rest of the code,
and it would have tests to prevent regressions. Bugs and extensions would
be handled via the normal patch process.
What am I missing?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions