<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 9:09 AM, Vlad Dumitrescu <span dir="ltr"><<a href="mailto:vladdu55@gmail.com" target="_blank">vladdu55@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Steve,<br>
<div class="im"><br>
On Fri, Feb 7, 2014 at 2:38 PM, Steve Vinoski <<a href="mailto:vinoski@ieee.org">vinoski@ieee.org</a>> wrote:<br>
> On Fri, Feb 7, 2014 at 3:29 AM, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br>
</div><div class="im">>> What is the official position regarding indenting multiline strings?<br>
>> If the emacs indentation code is broken, it means one can't reindent<br>
>> files without risking trouble...<br>
><br>
><br>
> You're trying to automate something that until now has not been automated,<br>
> at least not in public view to the best of my knowledge, so you're going to<br>
> hit problems like these. From what I've seen, users currently tend to indent<br>
> these problem areas manually so that they appear the way they would if<br>
> erlang-mode got them right.<br>
<br>
</div>Well, yes, I am trying to provide tools that will help people focus on<br>
what is important instead of having to remember which files can be<br>
reindented and which one can't (for example). Tools that work as<br>
expected, without nasty effects that may only be noticed later. The<br>
kind of tools that Joe and others asked for. If people are happy doing<br>
this kind of manual work, please let me know so that I can work on<br>
something more useful, but please don't say later that "the tools are<br>
crap".<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In order to be able to do that, there has to be a specification, so<br>
that people know what to expect. In this particular case, that<br>
specification would be an official indentation and formatting guide,<br>
that in practice would become the standard way of doing it. The<br>
current situation is that the emacs implementation is that<br>
specification (for indenting), except that it has some cases where it<br>
doesn't work. There are also some Erlang pretty printers<br>
(erl_prettypr, erl_tidy), but these have their problems too as they<br>
rely on the code to be parsable and I don't know how much their output<br>
matches that of the emacs indenter and with each other.<br></blockquote><div><br></div><div>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 been automated."</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wouldn't it be nice if there was an implementation independent<br>
specification? I am willing to put one together. This will make it<br>
much easier to make sure that the erlang support for different editors<br>
and IDEs is formatting the code in the same way and we can take the<br>
opportunity to specify (and maybe even implement) all the edge cases<br>
that emacs gets wrong.</blockquote><div><br></div><div>Yes, I understand the goal, and I provided my answers to your previous questions based on that understanding.</div><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>What am I missing?</div><div><br></div><div>--steve</div></div></div></div>