<div dir="ltr">A first step would be to have something like gofmt for Erlang.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 9:50 AM, Bengt Kleberg <span dir="ltr"><<a href="mailto:bengt.kleberg@ericsson.com" target="_blank">bengt.kleberg@ericsson.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
These are my opinions, not fact.<br>
<br>
It is unfortunate that formatting before check in it is not a viable<br>
way. To be honest I do not follow your reasons, but I accept them.<br>
I thought that since it is used in Go it would be possible for other<br>
languages as well.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
bengt<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, 2014-02-06 at 09:38 +0100, Loïc Hoguin wrote:<br>
> You can't reasonably do it when merging. You would have to amend each<br>
> commit individually with the whitespace fixes. Then you would have to<br>
> test again, because your whitespace program may have broken your own<br>
> program.<br>
><br>
> Plus this doesn't help your code get merged at all. If you submit code<br>
> with broken whitespace, then tools will also display this whitespace<br>
> change. You can of course hide whitespace changes, but the problem is<br>
> that whitespace does matter in some places, so you're basically hiding<br>
> potentially important information by doing that.<br>
><br>
> I also highly doubt that "the owner would be able to accept more code".<br>
> Like I said before, this is a minor annoyance at best.<br>
><br>
> He wouldn't appear nicer either, because he has to spend extra time on<br>
> each PR, meaning they get merged slower, which is a bigger annoyance<br>
> than telling people to fix the whitespace they broke.<br>
><br>
> The contributor can quickly see if they broke whitespace after<br>
> submitting the PR on github by looking at the diff tab. I'm always<br>
> surprised when people submit a PR with obviously broken whitespace and<br>
> do nothing about it until I point it out.<br>
><br>
> Contributors aren't the ones who are going to maintain the code. They<br>
> just write and forget. Therefore they should be the ones who make sure<br>
> that what they submit is well-formed so as to not become an<br>
> inconvenience to the project owner, who is going to maintain their code<br>
> for them for free.<br>
><br>
> On 02/06/2014 08:30 AM, Bengt Kleberg wrote:<br>
> > Greetings,<br>
> ><br>
> > These are opinions, not facts.<br>
> ><br>
> > It is correct that the project owner has decides what goes into the<br>
> > project. Why would it be a bad idea for this owner to automatically<br>
> > format every thing that is checked in?<br>
> ><br>
> > On the plus side (s)he would be able to accept more code this way and<br>
> > appear nicer to would be contributers.<br>
> ><br>
> ><br>
> > bengt<br>
> ><br>
> > On Wed, 2014-02-05 at 22:18 +0100, Loïc Hoguin wrote:<br>
> >> On 02/05/2014 09:48 PM, Raoul Duke wrote:<br>
> >>>> One line? That's the worst solution ever. You break every tool ever, and<br>
> >>>> even make *cat* and *less* useless (pun intended).<br>
> >>>> Code is text, so keep it readable without requiring any special crappy<br>
> >>>> editor.<br>
> >>><br>
> >>> yes and no. these are the problems and solutions we have to trade off.<br>
> >>> what is the lesser evil in the long run? probably people disagree.<br>
> >><br>
> >> ???<br>
> >><br>
> >> There is no evil, this is at most a minor annoyance that comes with<br>
> >> pointless debates shrouded by blind religious beliefs.<br>
> >><br>
> >> The answer is always "submit code the way the project owner wants you<br>
> >> to" and no amount of debating is going to change that, ever.<br>
> >><br>
> >> It's not even just tabs vs spaces, plenty other minor things are the<br>
> >> author's choice, including number of columns, newline characters, source<br>
> >> code encoding, but also major things like mandatory documentation or<br>
> >> tests and backward compatibility.<br>
> >><br>
> >> There is no one true way of doing things, for this or for anything else.<br>
> >> It's just a matter of choice.<br>
> >><br>
> ><br>
> > _______________________________________________<br>
> > erlang-questions mailing list<br>
> > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> ><br>
><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>