[erlang-questions] Controversial subject of the day: tabs and spaces for indentation

[Vlad Dumitrescu]

Hi all,

It's been almost a full day since the last controversial issue was
discussed here and I feel it's time for a new one (well, it's actually
old).

The default indentation used by the erlang-mode uses a mix of tabs and
spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
is the common enemy!

Not everybody uses emacs, nor should they be forced to. This means
that creating a patch might take less time than adjusting the
whitespace afterwards, which feels a horrible waste of time and
energy.

Of course, we the non-emacs-using hackers of the OTP code might be in
a crushing minority, and then the issue will get closed quickly. I
feel however that I need to try to change this. I have abstained
before from submitting small fixes just because of this (instead I
sold the idea to someone else, but that doesn't always work).

So my question is: are enough people bothered by this issue? If yes,
can we try to agree on a solution? Such changes are best done in
connection with a release.

best regards,
Vlad
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Andrew Thompson]

On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote:
> Hi all,
>
> It's been almost a full day since the last controversial issue was
> discussed here and I feel it's time for a new one (well, it's actually
> old).
>
> The default indentation used by the erlang-mode uses a mix of tabs and
> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
> is the common enemy!

As a vim user, I find the emacs indent mode for erlang incredibly
annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs
and spaces makes erlang files a horrible mess when your tabstop is not
8.

Andrew

[Garrett Smith]

On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson <and...@hijacked.us> wrote:
> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote:
>> Hi all,
>>
>> It's been almost a full day since the last controversial issue was
>> discussed here and I feel it's time for a new one (well, it's actually
>> old).
>>
>> The default indentation used by the erlang-mode uses a mix of tabs and
>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
>> is the common enemy!
>
> As a vim user, I find the emacs indent mode for erlang incredibly
> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs
> and spaces makes erlang files a horrible mess when your tabstop is not
> 8.

I'm curious what the argument *for* mixed tabs and spaces is. It is to
save precious disk space?

Garrett

P.S. I agree, going two to three days without religious material on
the Erlang list is, well, it's just hard to go back now.

[Loïc Hoguin]

On 02/05/2014 07:35 PM, Garrett Smith wrote:
> On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson <and...@hijacked.us> wrote:
>> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote:
>>> Hi all,
>>>
>>> It's been almost a full day since the last controversial issue was
>>> discussed here and I feel it's time for a new one (well, it's actually
>>> old).
>>>
>>> The default indentation used by the erlang-mode uses a mix of tabs and
>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
>>> is the common enemy!
>>
>> As a vim user, I find the emacs indent mode for erlang incredibly
>> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs
>> and spaces makes erlang files a horrible mess when your tabstop is not
>> 8.
>
> I'm curious what the argument *for* mixed tabs and spaces is. It is to
> save precious disk space?

The argument isn't very interesting, intent is much more so. It all
comes from one guy who figured a way to troll everyone alive at the time
plus all future generations forever, and succeeded.

--
Loïc Hoguin
http://ninenines.eu

[Ulf Wiger]

One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module:

%% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*-

(Perhaps others have suggestions for the ultimate settings here)

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com

[Garrett Smith]

On Wed, Feb 5, 2014 at 12:39 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> On 02/05/2014 07:35 PM, Garrett Smith wrote:
>>
>> On Wed, Feb 5, 2014 at 12:27 PM, Andrew Thompson <and...@hijacked.us>
>> wrote:
>>>
>>> On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote:
>>>>
>>>> Hi all,
>>>>
>>>> It's been almost a full day since the last controversial issue was
>>>> discussed here and I feel it's time for a new one (well, it's actually
>>>> old).
>>>>
>>>> The default indentation used by the erlang-mode uses a mix of tabs and
>>>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
>>>> is the common enemy!
>>>
>>>
>>> As a vim user, I find the emacs indent mode for erlang incredibly
>>> annoying to 'fake' by hand. I'd love to see the tabs die as mixing tabs
>>> and spaces makes erlang files a horrible mess when your tabstop is not
>>> 8.
>>
>>
>> I'm curious what the argument *for* mixed tabs and spaces is. It is to
>> save precious disk space?
>
>
> The argument isn't very interesting, intent is much more so. It all comes
> from one guy who figured a way to troll everyone alive at the time plus all
> future generations forever, and succeeded.

So this is actually an opportunity, over the course of 6 - 12 hours
per day, to check one's arrogance and hubris - to be a more humble and
modest person? I can see an advantage here.

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 7:40 PM, Ulf Wiger <u...@feuerlabs.com> wrote:
>
> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module:
>
> %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*-
>
> (Perhaps others have suggestions for the ultimate settings here)

That (or whatever we agree on) would help a lot. The heavy question is
- is it reasonable to change accordingly all OTP source files? Maybe
just before setting the final 17.0.0 tag (or some other convenient
moment)?

By the way, there is another golden rule that the OTP sources are
challenging: trailing spaces on lines... Here I think that the problem
are the emacs templates, as almost all cases I've seen are in
comments.

[Björn-Egil Dahlberg]

This is a war worth winning but it feels like every battle has been a
loss so far ..

As a member of the OTP-team and the *only* vim user, I can say that the
rest of OTP has utter disinterest to change the current format. (or so
it seems anyway =)

I guess Emacs does not allow indentation to be anything other than horrible.

Every time I've brought it up there is whining about some precious
little elisp file that can't handle the change.

I've gotten harassed on the number of '%' comment characters I'm
supposed to use for different context .. otherwise Emacs just explodes
.. or something.

Ok, so perhaps I'm being a bit dramatic here =)

The truth is that a lot of code in otp is emacs:ified - that is the
convention. I think it's bad - but i've managed.

Tabs are problematic because code-rendering tools for reviewing code has
a lot of issues with it. *We should remove them*, but I'll guess hell
will freeze over well before that happens.

// Björn-Egil

[Raoul Duke]

> I guess Emacs does not allow indentation to be anything other than horrible.
> Every time I've brought it up there is whining about some precious little
> elisp file that can't handle the change.
> I've gotten harassed on the number of '%' comment characters I'm supposed to
> use for different context .. otherwise Emacs just explodes .. or something.
> Ok, so perhaps I'm being a bit dramatic here =)

personally i found this funny and poignant and great. i am an emacs
user, but i am not am emacs bigot. i'm a usability bigot. so i love it
when things like this come up and people point out what is stupid
wrong about the emacs-emperor-with-no-clothes.

[Mike Oxford]

Convert it all to tabs; there's no sane reason for mixing them.

For emacs users:  %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*-

For vi users:  modify $HOME/.vimrc to set the width you want

/thread

And toilet-paper is to be placed on the spool with the loose end out over the top and near the user so it does not lay flat against the wall.

[Magnus Henoch]

Ulf Wiger <u...@feuerlabs.com> writes:

> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module:
>
> %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*-
>
> (Perhaps others have suggestions for the ultimate settings here)

As of Emacs 23, you can specify settings for an entire directory tree by
creating a .dir-locals.el file in the top directory. It needs to be in
Lisp format, so pay attention to dots and parentheses:

((erlang-mode
(erlang-indent-level . 4)
(show-trailing-whitespace . t)
;; http://www.emacswiki.org/emacs/TabsSpacesBoth
(indent-tabs-mode . nil)))

Regards,
Magnus

[Garrett Smith]

It seems to me that this problem is easily solved by inverting the interests:

- Fix erlang-mode to default to all spaces

- OTP team includes the appropriate Emacs code headers in the source
files (or the dot file in the source root directory as Magnus just
pointed out) and leave them horribly formatted, per their preference

Does this not trivially solve the world's Erlang indent problems?

Garrett

[Raoul Duke]

> - Fix erlang-mode to default to all spaces
>
> - OTP team includes the appropriate Emacs code headers in the source
> files (or the dot file in the source root directory as Magnus just
> pointed out) and leave them horribly formatted, per their preference
>
> Does this not trivially solve the world's Erlang indent problems?

<pipe-dream>

i think the general problem is that whatever will be enforced is
enforced by the writer, not by the consumer. formatting should ideally
always be subjective and subjectively controlled. so i can see things
*how i want* (dammit) and *so can you* (even if you swing a different
way when it comes to formatting).

the problem is that tools don't take this perspective, so simple
things like diff end up spitting out horrible answers under such
conditions.

so everybody assumes that we *must* have it be pushed / agreed upon.

all wrong wrong wrong personally i believe.

the tools have to change. the computers have to serve the people, not
the other way around. so any language should have a fundamental markup
version of itself, say some xml schema, and everything is done under
the covers in that format. then when presented to the user it is
converted to their subjective preferred rendering style.

</pipe-dream>

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith <g...@rre.tt> wrote:
> It seems to me that this problem is easily solved by inverting the interests:
>
> - Fix erlang-mode to default to all spaces
>
> - OTP team includes the appropriate Emacs code headers in the source
> files (or the dot file in the source root directory as Magnus just
> pointed out) and leave them horribly formatted, per their preference
>
> Does this not trivially solve the world's Erlang indent problems?

Unfortunately, no. If I make a patch without emacs, my editor will
still use something else than a mix of tabs and spaces, so it will
have to be OTP-ified by hand (copying indentation from other lines) or
by running it through emacs just for that.

Which, in a funny turn of events, brings me to a question related to
the previous "holy war": can emacs open, reindent and save files in
bach mode? That would indeed help! (even if one would still have to
install emacs).

/Vlad

[Garrett Smith]

On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu <vlad...@gmail.com> wrote:
> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith <g...@rre.tt> wrote:
>> It seems to me that this problem is easily solved by inverting the interests:
>>
>> - Fix erlang-mode to default to all spaces
>>
>> - OTP team includes the appropriate Emacs code headers in the source
>> files (or the dot file in the source root directory as Magnus just
>> pointed out) and leave them horribly formatted, per their preference
>>
>> Does this not trivially solve the world's Erlang indent problems?
>
> Unfortunately, no. If I make a patch without emacs, my editor will
> still use something else than a mix of tabs and spaces, so it will
> have to be OTP-ified by hand (copying indentation from other lines) or
> by running it through emacs just for that.
>
> Which, in a funny turn of events, brings me to a question related to
> the previous "holy war": can emacs open, reindent and save files in
> bach mode? That would indeed help! (even if one would still have to
> install emacs).

This seems like a problem that can be confined to the OTP team and
process, which is I think is a pretty small subset of all erlang-mode
users, no? And changing erlang-mode to default to spaces doesn't make
this worse does it?

Garrett

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 8:27 PM, Garrett Smith <g...@rre.tt> wrote:
> On Wed, Feb 5, 2014 at 1:24 PM, Vlad Dumitrescu <vlad...@gmail.com> wrote:
>> On Wed, Feb 5, 2014 at 8:18 PM, Garrett Smith <g...@rre.tt> wrote:
>>> It seems to me that this problem is easily solved by inverting the interests:
>>> - Fix erlang-mode to default to all spaces
>>> - OTP team includes the appropriate Emacs code headers in the source
>>> files (or the dot file in the source root directory as Magnus just
>>> pointed out) and leave them horribly formatted, per their preference
>>>
>>> Does this not trivially solve the world's Erlang indent problems?
>>
>> Unfortunately, no. If I make a patch without emacs, my editor will
>> still use something else than a mix of tabs and spaces, so it will
>> have to be OTP-ified by hand (copying indentation from other lines) or
>> by running it through emacs just for that.
>>
>> Which, in a funny turn of events, brings me to a question related to
>> the previous "holy war": can emacs open, reindent and save files in
>> bach mode? That would indeed help! (even if one would still have to
>> install emacs).
>
> This seems like a problem that can be confined to the OTP team and
> process, which is I think is a pretty small subset of all erlang-mode
> users, no? And changing erlang-mode to default to spaces doesn't make
> this worse does it?

You are right, it's better like you suggested and definitely a step in
the right direction. But I think that most Erlang projects are more
lenient regarding whitespace mismatches in patches (being much
smaller) and thus the project where it hurts the most to be
non-compliant is not going to be affected. Yet.

/Vlad

[Fred Hebert]

I tended to solve that problem by opening a file, automatically
substituting a tab by 8 spaces (:%s/\t/ /g) and doing the
opposite at the end of my editing session (:%s/ /\t/g).

Nobody on the OTP team has yelled at me so far, so I kept doing that
whenever I played around that code base.

-Fred.

[kraythe .]

Actually the solution to this age old debate was proposed to me by a friend of mine and its genius on a number of levels but isn't implemented anywhere.  The reality is that for most languages whitespace is irrelevant so it shouldn't be the code holding the indentation but the user's preference file. Imagine a source code repository where there is NO irrelevant whitespace in the code base. For java, for example, there would be literally only one single line of code. Now when you check out you have a preference file that says you want tabs or spaces or mixed and also defines the other formatting you prefer. When you check out the system reformats the code according to your specs dynamically. When you commit, it strips your code of whitespace before comparing. 

Now that would rock. Not just for tabs but the other code holy wars like drop braces and so onl 

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <kra...@gmail.com> wrote:

Actually the solution to this age old debate was proposed to me by a friend of mine and its genius on a number of levels but isn't implemented anywhere.  The reality is that for most languages whitespace is irrelevant so it shouldn't be the code holding the indentation but the user's preference file. Imagine a source code repository where there is NO irrelevant whitespace in the code base. For java, for example, there would be literally only one single line of code. Now when you check out you have a preference file that says you want tabs or spaces or mixed and also defines the other formatting you prefer. When you check out the system reformats the code according to your specs dynamically. When you commit, it strips your code of whitespace before comparing. 

Now that would rock. Not just for tabs but the other code holy wars like drop braces and so onl 

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 9:21 PM, kraythe . <kra...@gmail.com> wrote:
> Actually the solution to this age old debate was proposed to me by a friend
> of mine and its genius on a number of levels but isn't implemented anywhere.
> The reality is that for most languages whitespace is irrelevant so it
> shouldn't be the code holding the indentation but the user's preference
> file. Imagine a source code repository where there is NO irrelevant
> whitespace in the code base. For java, for example, there would be literally
> only one single line of code. Now when you check out you have a preference
> file that says you want tabs or spaces or mixed and also defines the other
> formatting you prefer. When you check out the system reformats the code
> according to your specs dynamically. When you commit, it strips your code of
> whitespace before comparing.

Absolutely, this would fix it. But we don't have tools that can handle
that yet and I fear that implementing those and convincing people to
use them would take longer than agreeing on a saner alternative for
whitespace.

regards,
Vlad

[Garrett Smith]

On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <kra...@gmail.com> wrote:
> Actually the solution to this age old debate was proposed to me by a friend
> of mine and its genius on a number of levels but isn't implemented anywhere.
> The reality is that for most languages whitespace is irrelevant so it
> shouldn't be the code holding the indentation but the user's preference
> file. Imagine a source code repository where there is NO irrelevant
> whitespace in the code base. For java, for example, there would be literally
> only one single line of code. Now when you check out you have a preference
> file that says you want tabs or spaces or mixed and also defines the other
> formatting you prefer. When you check out the system reformats the code
> according to your specs dynamically. When you commit, it strips your code of
> whitespace before comparing.
>
> Now that would rock. Not just for tabs but the other code holy wars like
> drop braces and so onl

Heh, not bad. I wonder how something like this might evolve.

Garrett

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 9:28 PM, Garrett Smith <g...@rre.tt> wrote:
> On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <kra...@gmail.com> wrote:
>> Actually the solution to this age old debate was proposed to me by a friend
>> of mine and its genius on a number of levels but isn't implemented anywhere.
>> The reality is that for most languages whitespace is irrelevant so it
>> shouldn't be the code holding the indentation but the user's preference
>> file. Imagine a source code repository where there is NO irrelevant
>> whitespace in the code base. For java, for example, there would be literally
>> only one single line of code. Now when you check out you have a preference
>> file that says you want tabs or spaces or mixed and also defines the other
>> formatting you prefer. When you check out the system reformats the code
>> according to your specs dynamically. When you commit, it strips your code of
>> whitespace before comparing.
>

> Heh, not bad. I wonder how something like this might evolve.

Actually, if you have two scripts that add/remove whitespace (for now
I'd keep the newlines so that diff gives better results) you could
hook them into git's pre-commit and post-checkout hooks. I don't know
which other VCS allow this.

Of course, this will require everybody to have converters for all
languages (one doesn't know what might be in a repository). Maybe git
could have special hooks that are actually stored in the repository,
so one can get them from there?

regards,
Vlad

[Mark Allen]

The golang "go fmt" command parses the programmatic AST and returns human
readable text formatted to a configurable style sheet. They also have "go
fix" which parses the AST and dynamically replaces opcodes/sequences with
upgraded opcodes/sequences when moving from version 1.X.X -> 1.X.Y

It's kind of cool, but the pre-defined golang style is tabs only for
indentation (no spaces) which drives me insane, but at least its
consistent.

Mark

[Loïc Hoguin]

One line? That's the worst solution ever. You break every tool ever, and
even make *cat* and *less* useless (pun intended).

Code is text, so keep it readable without requiring any special crappy
editor.

On 02/05/2014 09:21 PM, kraythe . wrote:
> Actually the solution to this age old debate was proposed to me by a
> friend of mine and its genius on a number of levels but isn't
> implemented anywhere. The reality is that for most languages whitespace
> is irrelevant so it shouldn't be the code holding the indentation but
> the user's preference file. Imagine a source code repository where there
> is NO irrelevant whitespace in the code base. For java, for example,
> there would be literally only one single line of code. Now when you
> check out you have a preference file that says you want tabs or spaces
> or mixed and also defines the other formatting you prefer. When you
> check out the system reformats the code according to your specs
> dynamically. When you commit, it strips your code of whitespace before
> comparing.
>
> Now that would rock. Not just for tabs but the other code holy wars like
> drop braces and so onl
>

> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/
> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/

>
>
> On Wed, Feb 5, 2014 at 2:21 PM, kraythe . <kra...@gmail.com
> <mailto:kra...@gmail.com>> wrote:
>
> Actually the solution to this age old debate was proposed to me by a
> friend of mine and its genius on a number of levels but isn't
> implemented anywhere. The reality is that for most languages
> whitespace is irrelevant so it shouldn't be the code holding the
> indentation but the user's preference file. Imagine a source code
> repository where there is NO irrelevant whitespace in the code base.
> For java, for example, there would be literally only one single line
> of code. Now when you check out you have a preference file that says
> you want tabs or spaces or mixed and also defines the other
> formatting you prefer. When you check out the system reformats the
> code according to your specs dynamically. When you commit, it strips
> your code of whitespace before comparing.
>
> Now that would rock. Not just for tabs but the other code holy wars
> like drop braces and so onl
>

> *Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
> /Author of: Hardcore Java (2003) and Maintainable Java (2012)/
> /LinkedIn: //http://www.linkedin.com/pub/robert-simmons/40/852/a39/

> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
> http://erlang.org/mailman/listinfo/erlang-questions

>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
http://ninenines.eu

[Raoul Duke]

> One line? That's the worst solution ever. You break every tool ever, and
> even make *cat* and *less* useless (pun intended).
> Code is text, so keep it readable without requiring any special crappy
> editor.

yes and no. these are the problems and solutions we have to trade off.
what is the lesser evil in the long run? probably people disagree.

[Loïc Hoguin]

On 02/05/2014 09:48 PM, Raoul Duke wrote:
>> One line? That's the worst solution ever. You break every tool ever, and
>> even make *cat* and *less* useless (pun intended).
>> Code is text, so keep it readable without requiring any special crappy
>> editor.
>
> yes and no. these are the problems and solutions we have to trade off.
> what is the lesser evil in the long run? probably people disagree.

???

There is no evil, this is at most a minor annoyance that comes with
pointless debates shrouded by blind religious beliefs.

The answer is always "submit code the way the project owner wants you
to" and no amount of debating is going to change that, ever.

It's not even just tabs vs spaces, plenty other minor things are the
author's choice, including number of columns, newline characters, source
code encoding, but also major things like mandatory documentation or
tests and backward compatibility.

There is no one true way of doing things, for this or for anything else.
It's just a matter of choice.

--
Loïc Hoguin
http://ninenines.eu

[Steve Vinoski]

On Wed, Feb 5, 2014 at 2:27 PM, Garrett Smith <g...@rre.tt> wrote:

This seems like a problem that can be confined to the OTP team and
process, which is I think is a pretty small subset of all erlang-mode
users, no? And changing erlang-mode to default to spaces doesn't make
this worse does it?

erlang-mode allows the use of spaces for indentation just fine. If the emacs-lisp variable indent-tabs-mode is set to t, you get tabs, or if nil, you get spaces -- this is pretty much universal across all Emacs programming language modes.

My ~/.emacs defaults indent-tabs-mode to nil, but I have custom file-open hooks for Erlang and C that search for tabs at the beginnings of lines when I open a source file, and if found, set indent-tabs-mode to t for that buffer only so that any edits there match the existing style for that file.

--steve

P.S. I'd like the bikeshed to be grey.

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 10:18 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
>
> There is no evil, this is at most a minor annoyance that comes with
> pointless debates shrouded by blind religious beliefs.
>
> The answer is always "submit code the way the project owner wants you to"
> and no amount of debating is going to change that, ever.
>
> It's not even just tabs vs spaces, plenty other minor things are the
> author's choice, including number of columns, newline characters, source
> code encoding, but also major things like mandatory documentation or tests
> and backward compatibility.

All true, except that as a project owner I want to make it as easy as
possible for people to contribute. As it is now, people who don't use
emacs have to do a more tedious work just to match whitespace... I
don't like that kind of useless work and it makes me less motivated to
submit patches.

If it's deemed that we are a minority not worth considering changing
the defaults, then fine. At least it's an explicit choice and we know
exactly what is going on.

If the debate uncovers some workarounds that make the pain less
painful (pun intended), then even better.

regards,
Vlad

[Raoul Duke]

> The answer is always "submit code the way the project owner wants you to"
> and no amount of debating is going to change that, ever.
>
> It's not even just tabs vs spaces, plenty other minor things are the
> author's choice, including number of columns, newline characters, source
> code encoding, but also major things like mandatory documentation or tests
> and backward compatibility.
>
> There is no one true way of doing things, for this or for anything else.
> It's just a matter of choice.

this is an amusing way to use the term "choice". choice would be
better if both "sides", the author and the reader, could have things
the way they want, rather than any one being a dictator.

and it is technically possible, if not politically. probably all
computer programming languages (at least, that i care about :-) have
an ast form.

hell, one could look toward xslt or something for ideas (talk about evil! ;-).

[Vlad Dumitrescu]

> If the debate uncovers some workarounds that make the pain less
> painful (pun intended), then even better.

I just found out that we could do something like this to reindent files:

emacs -batch sample.erl --eval '(indent-region (point-min) (point-max)
nil)' -f save-buffer

/Vlad

[kraythe .]

I have long favored the enforcement of coding style at the repository level. Then it doesnt matter if someone accidentally reformats their local copy, the checkin will reformat it accordingly. I dont think people will ever agree on the "right" format in something that is inherently a matter of taste. I like tight code with only 2 char indents and as much on the screen at once. Another guy I know loves drop braces with a brace on the next line (for java, C, etc). Neither of us is wrong. If the repo checkin had a reformatter, it wouldn't matter. 

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

[Michael Truog]

On 02/05/2014 10:40 AM, Ulf Wiger wrote:
> One thing for emacs users (or those who need to deal with them) to do is to insert the following at the top of each erlang module:
>
> %% -*- erlang-indent-level: 4; indent-tabs-mode: nil -*-
>
> (Perhaps others have suggestions for the ultimate settings here)

The ULTIMATE modeline settings should be:
%-*-Mode:erlang;coding:utf-8;tab-width:4;c-basic-offset:4;indent-tabs-mode:()-*-
% ex: set ft=erlang fenc=utf-8 sts=4 ts=4 sw=4 et:

latin1 would need to be used for the older Erlang source code that requires it (probably all of OTP) which unfortunately makes the emacs modeline more than 80 characters. Having both an emacs and a vi modeline can keep both sets of users happy.

It is typical to avoid tabs and prefer spaces, so it would be nice to have that be standard, since the OTP code is becoming unreadable due to characters that don't matter (due to not making a decision, you are still deciding to allow both tabs and spaces). Tab stops were never standard and only really relate to typewriters historically (who uses those for Erlang?).

>
>
> BR,
> Ulf W

>
> On 5 Feb 2014, at 19:14, Vlad Dumitrescu <vlad...@gmail.com> wrote:
>
>> Hi all,
>>
>> It's been almost a full day since the last controversial issue was
>> discussed here and I feel it's time for a new one (well, it's actually
>> old).
>>
>> The default indentation used by the erlang-mode uses a mix of tabs and
>> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
>> is the common enemy!
>>

>> Not everybody uses emacs, nor should they be forced to. This means
>> that creating a patch might take less time than adjusting the
>> whitespace afterwards, which feels a horrible waste of time and
>> energy.
>>
>> Of course, we the non-emacs-using hackers of the OTP code might be in
>> a crushing minority, and then the issue will get closed quickly. I
>> feel however that I need to try to change this. I have abstained
>> before from submitting small fixes just because of this (instead I
>> sold the idea to someone else, but that doesn't always work).
>>
>> So my question is: are enough people bothered by this issue? If yes,
>> can we try to agree on a solution? Such changes are best done in
>> connection with a release.
>>
>> best regards,
>> Vlad

>> _______________________________________________
>> erlang-questions mailing list
>> erlang-q...@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions

> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com

>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

> .

[Loïc Hoguin]

On 02/05/2014 10:32 PM, Vlad Dumitrescu wrote:
> If the debate uncovers some workarounds that make the pain less
> painful (pun intended), then even better.

Have you read the previous threads? Numerous solutions were posted.
Here's a quick one for vim users:

http://erlang.org/pipermail/erlang-questions/2009-February/041719.html

And even better if you want it to also look good and close enough to get
your patch accepted:

http://stackoverflow.com/questions/4085411/vim-indent-like-emacs

(Values may be slightly different for erlang-mode, I don't have this
configured yet on this laptop.)

You can even use direnv to set an alias only for the erlang/otp folder
on your machine that would use a special configuration file that
includes those settings, so that you don't have to worry about it at
all. (And if you don't like the direnv solution, there's a few others,
including ones that only require vim.)

--
Loïc Hoguin
http://ninenines.eu

[Vlad Dumitrescu]

On Wed, Feb 5, 2014 at 10:46 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> On 02/05/2014 10:32 PM, Vlad Dumitrescu wrote:
>>
>> If the debate uncovers some workarounds that make the pain less
>> painful (pun intended), then even better.
>
>
> Have you read the previous threads? Numerous solutions were posted. Here's a
> quick one for vim users:

Yep. I don't use vim either. For me it's SublimeText or Eclipse. The
batch emacs should work fine, but it's still just a workaround.

/Vlad

[Anthony Ramine]

Hello Vlad,

My strategy with regard to indentation is to just expand all tabs on all the lines I edit or add to the code. And I just absolutely don’t care about it not being consistent with the mixed tabs and spaces around it.

With a correct tabstop (8 and only 8), it doesn’t matter anyway.

Regards,

--
Anthony Ramine

Le 5 févr. 2014 à 19:14, Vlad Dumitrescu <vlad...@gmail.com> a écrit :

> Hi all,
>
> It's been almost a full day since the last controversial issue was
> discussed here and I feel it's time for a new one (well, it's actually
> old).
>
> The default indentation used by the erlang-mode uses a mix of tabs and
> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
> is the common enemy!
>
> Not everybody uses emacs, nor should they be forced to. This means
> that creating a patch might take less time than adjusting the
> whitespace afterwards, which feels a horrible waste of time and
> energy.
>
> Of course, we the non-emacs-using hackers of the OTP code might be in
> a crushing minority, and then the issue will get closed quickly. I
> feel however that I need to try to change this. I have abstained
> before from submitting small fixes just because of this (instead I
> sold the idea to someone else, but that doesn't always work).
>
> So my question is: are enough people bothered by this issue? If yes,
> can we try to agree on a solution? Such changes are best done in
> connection with a release.
>
> best regards,
> Vlad

[Steve Davis]

Seems this eternal debate always revolves around the user's choice of text file viewers (note: plural).

Maybe a better way to resolve this annoying and persistent question is to ask: "what is the correct binary format for a text file?".

If there's a clear answer to that, then we could say that any viewer that doesn't deal with that format "prettily" is flouting the spec.

2c.

/s

[Bengt Kleberg]

Greetings,

These are opinions, not facts.

The editors I use have a way to change the size of a tabstop. The word
processors I use have a way to change the size of each tabstop level. If
8 was the correct number these possibilities would not be present.

bengt

On Wed, 2014-02-05 at 22:58 +0100, Anthony Ramine wrote:
> Hello Vlad,
>
> My strategy with regard to indentation is to just expand all tabs on all the lines I edit or add to the code. And I just absolutely don’t care about it not being consistent with the mixed tabs and spaces around it.
>
> With a correct tabstop (8 and only 8), it doesn’t matter anyway.
>
> Regards,
>

_______________________________________________

[Bengt Kleberg]

Greetings,

These are opinions, not facts.

How do we know that tab stops where never standard?


bengt

[Bengt Kleberg]

Greetings,

These are opinions, not facts.

I think that formatting code as it goes into the repository is a good
thing. What are the arguments against it?


bengt

[Bengt Kleberg]

Greetings,

These are opinions, not facts.

It is correct that the project owner has decides what goes into the
project. Why would it be a bad idea for this owner to automatically
format every thing that is checked in?

On the plus side (s)he would be able to accept more code this way and
appear nicer to would be contributers.


bengt

On Wed, 2014-02-05 at 22:18 +0100, Loïc Hoguin wrote:
> On 02/05/2014 09:48 PM, Raoul Duke wrote:
> >> One line? That's the worst solution ever. You break every tool ever, and
> >> even make *cat* and *less* useless (pun intended).
> >> Code is text, so keep it readable without requiring any special crappy
> >> editor.
> >
> > yes and no. these are the problems and solutions we have to trade off.
> > what is the lesser evil in the long run? probably people disagree.
>
> ???
>
> There is no evil, this is at most a minor annoyance that comes with
> pointless debates shrouded by blind religious beliefs.
>
> The answer is always "submit code the way the project owner wants you
> to" and no amount of debating is going to change that, ever.
>
> It's not even just tabs vs spaces, plenty other minor things are the
> author's choice, including number of columns, newline characters, source
> code encoding, but also major things like mandatory documentation or
> tests and backward compatibility.
>
> There is no one true way of doing things, for this or for anything else.
> It's just a matter of choice.
>

[Bengt Kleberg]

Greetings,

These are opinions, not facts.

Go is a cool language in many places. This is one place.

The use of one tab for one level of indention is logical. The indention
level is 1, so why have another amount of characters? The only reason I
have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All
editors that I use can make 1 tab take up whatever width I like for
indentation.


bengt

[Valentin Micic]

Dear Bengt,

I'd like to ask you a question… when you say:

"These are opinions, not facts."

Do you mean it in a way that "what follows are my opinions and not facts"?
Or do you mean that views expressed by an email that you're quoting are (in your opinion) opinions and not facts?
Or both?

And, if you do not mind indulging me for a moment -- why do you think it is necessary to put forward such a preamble?

Kind reagards

V/

[Michael Truog]

On 02/05/2014 11:21 PM, Bengt Kleberg wrote:
> Greetings,
>
> These are opinions, not facts.
>
> How do we know that tab stops where never standard?

We know by reading about tab stops:
http://en.wikipedia.org/wiki/Tab_stop
"Tab stops are set manually, ..."

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

So you mean that tabstops on a typewriter where never standard because
they where set manually. OK, fair enough.

How is that pertinent to indenting computer source code?


bengt

[Loïc Hoguin]

You can't reasonably do it when merging. You would have to amend each
commit individually with the whitespace fixes. Then you would have to
test again, because your whitespace program may have broken your own
program.

Plus this doesn't help your code get merged at all. If you submit code
with broken whitespace, then tools will also display this whitespace
change. You can of course hide whitespace changes, but the problem is
that whitespace does matter in some places, so you're basically hiding
potentially important information by doing that.

I also highly doubt that "the owner would be able to accept more code".
Like I said before, this is a minor annoyance at best.

He wouldn't appear nicer either, because he has to spend extra time on
each PR, meaning they get merged slower, which is a bigger annoyance
than telling people to fix the whitespace they broke.

The contributor can quickly see if they broke whitespace after
submitting the PR on github by looking at the diff tab. I'm always
surprised when people submit a PR with obviously broken whitespace and
do nothing about it until I point it out.

Contributors aren't the ones who are going to maintain the code. They
just write and forget. Therefore they should be the ones who make sure
that what they submit is well-formed so as to not become an
inconvenience to the project owner, who is going to maintain their code
for them for free.

--
Loïc Hoguin
http://ninenines.eu

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

Thank you for the feedback. Hopefully the new version makes things
clearer. If not, please do not hesitate to help me make it better.

The opinions statement that I start my email with has become necessary
since some people on erlang-questions explained in a belligerent way
that they had previously never seen opinions expressed as something that
might be mistaken for facts. They surely where from a part of the
Internet that I have never seen, but it takes only a little sentence to
make them happy.

bengt

[Bengt Kleberg]

Greetings,

These are my opinions, not fact.

It is unfortunate that formatting before check in it is not a viable
way. To be honest I do not follow your reasons, but I accept them.
I thought that since it is used in Go it would be possible for other
languages as well.


bengt

[Ali Sabil]

A first step would be to have something like gofmt for Erlang.

[Vlad Dumitrescu]

On Thu, Feb 6, 2014 at 9:38 AM, Loïc Hoguin <es...@ninenines.eu> wrote:
> The contributor can quickly see if they broke whitespace after submitting
> the PR on github by looking at the diff tab. I'm always surprised when
> people submit a PR with obviously broken whitespace and do nothing about it
> until I point it out.

As an interesting anecdote, yesterday I managed somehow to produce a
patch that looked good on github, but not in emacs... So unfortunately
it seems that checking GH might not be enough (at least not when not
using emacs in the first place).

regards,
Vlad

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

We have erl_tidy:file/2 that ought to be a good starting point to mimic
gofmt.


bengt

[Lukas Larsson]

On Thu, Feb 6, 2014 at 9:38 AM, Loïc Hoguin <es...@ninenines.eu> wrote:

Plus this doesn't help your code get merged at all. If you submit code with broken whitespace, then tools will also display this whitespace change. You can of course hide whitespace changes, but the problem is that whitespace does matter in some places, so you're basically hiding potentially important information by doing that.

This is in my opinion the reason why it would be a very bad thing to do a huge commit that changes the current whitespace format of a project to another. It is already very hard to figure out what change could have caused a bug without having to deal with whitespace changes in the middle of a diff. 

[Benoit Chesneau]

well then commit a whitespace change diff, then the change you really wanted to make. It of course requires to have a standard defined at first :)

- benoit 

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 10:12 AM, Vlad Dumitrescu <vlad...@gmail.com> wrote:

On Thu, Feb 6, 2014 at 9:38 AM, Loïc Hoguin <es...@ninenines.eu> wrote:
> The contributor can quickly see if they broke whitespace after submitting
> the PR on github by looking at the diff tab. I'm always surprised when
> people submit a PR with obviously broken whitespace and do nothing about it
> until I point it out.

As an interesting anecdote, yesterday I managed somehow to produce a
patch that looked good on github, but not in emacs... So unfortunately
it seems that checking GH might not be enough (at least not when not
using emacs in the first place).

There are also differences between a `git diff` and github display sometimes... 

For myself I am surprised by the number of project owner not describing the standard they are following but expecting that others are following it. Which create frustration on each parts.

This why the gofmt tool or pep8 (even if I hate this one) are good. They allows a lot of people using the same language to follow the same guidelines. And provides tools to automatically fix them when needed. it removes a lot of frustration from each parts.

- benoit

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

So Erlang is sensitive to indention to the point of causing bugs. I did
not know that.


bengt

[Lukas Larsson]

For single commits this would work, but will not work when I want to do "git diff OTP_R14B03..OTP_17.0-rc1"

[Vlad Dumitrescu]

On Thu, Feb 6, 2014 at 10:31 AM, Lukas Larsson <lu...@erlang.org> wrote:

Yes, if such a thing would be done, the best time is as a separate
commit right before a release, this will minimize the number of
merges/rebases with mixed styles of indentation. Of course, as Lukas
points out, if diffing with older code, then you have a problem.

Anyway, I have a suggestion for a workaround at
https://gist.github.com/vladdu/8841089. Put those files in your ~/bin
(which should be on $PATH), edit them to match your system and style
and you can reindent files simply by running "erl-indent
/path/to/myfile.erl". It still requires to have emacs installed, but I
can live with that.

The downside is that if you want to use only spaces, then the whole
file will be changed to use them. The really big downside is that with
this tool there will be even less incitament to change the indentation
style...

regards,
Vlad

[Benoit Chesneau]

Ah sure, but I never heard of any good solution to fix the past in one pass. Imo  slowly fixing step by step, changees by changes would be enough. At list the large diff expose the issue for those who care.

- benoit

  

[Lukas Larsson]

On Thu, Feb 6, 2014 at 10:40 AM, Bengt Kleberg <bengt....@ericsson.com> wrote:

Greetings,

These are my opinions, not facts.

So Erlang is sensitive to indention to the point of causing bugs. I did
not know that.

It is not the indentation but changes to whitespace in strings that could cause issues.

[Aaron France]

UNSUBSCRIBE

On Wed, Feb 05, 2014 at 07:14:30PM +0100, Vlad Dumitrescu wrote:
> Hi all,
>
> It's been almost a full day since the last controversial issue was
> discussed here and I feel it's time for a new one (well, it's actually
> old).
>
> The default indentation used by the erlang-mode uses a mix of tabs and
> spaces. Whatever side one is in the "tabs vs spaces" war, mixing them
> is the common enemy!
>
> Not everybody uses emacs, nor should they be forced to. This means
> that creating a patch might take less time than adjusting the
> whitespace afterwards, which feels a horrible waste of time and
> energy.
>
> Of course, we the non-emacs-using hackers of the OTP code might be in
> a crushing minority, and then the issue will get closed quickly. I
> feel however that I need to try to change this. I have abstained
> before from submitting small fixes just because of this (instead I
> sold the idea to someone else, but that doesn't always work).
>
> So my question is: are enough people bothered by this issue? If yes,
> can we try to agree on a solution? Such changes are best done in
> connection with a release.
>

> best regards,

[Vance Shipley]

On Wed, Feb 5, 2014 at 9:21 PM, kraythe . <kra...@gmail.com> wrote:
} Actually the solution to this age old debate was proposed to me by a friend
} of mine and its genius on a number of levels but isn't implemented anywhere.
} The reality is that for most languages whitespace is irrelevant so it
} shouldn't be the code holding the indentation but the user's preference
} file. Imagine a source code repository where there is NO irrelevant
} whitespace in the code base. For java, for example, there would be literally
} only one single line of code. Now when you check out you have a preference
} file that says you want tabs or spaces or mixed and also defines the other
} formatting you prefer. When you check out the system reformats the code
} according to your specs dynamically. When you commit, it strips your code of
} whitespace before comparing.

I was inspired by my loathe of emacs indentation to consider how to
solve the style problems completely. My solution goes a step further
than what is proposed above. I would keep only the Abstract Syntax
in the repository. The repository tools (git, svn, etc.) would be
extended to run the appropriate tool (syntax_tools) on checkout/commit.
Each user could have any presentation they wanted. If you like your
';' before the case clause you get that style 'cause that's what your
tools are configured for. All style debates would be ended.

On Wed, Feb 05, 2014 at 09:27:35PM +0100, Vlad Dumitrescu wrote:
} Absolutely, this would fix it. But we don't have tools that can handle
} that yet and I fear that implementing those and convincing people to
} use them would take longer than agreeing on a saner alternative for
} whitespace.

When I first suggested this I was quickly reminded that all preprocessor
information would be lost. There would be no macros and no comments.

But didn't you solve that problem in Erlide Vlad? I remember looking
and seeing where you were doing preservation of macros and comments
when working with abstract syntax.


--
-Vance

http://erlang.org/pipermail/erlang-questions/2004-November/013620.html

[Vlad Dumitrescu]

On Thu, Feb 6, 2014 at 11:46 AM, Vance Shipley <van...@motivity.ca> wrote:
> I was inspired by my loathe of emacs indentation to consider how to
> solve the style problems completely. My solution goes a step further
> than what is proposed above. I would keep only the Abstract Syntax
> in the repository. The repository tools (git, svn, etc.) would be
> extended to run the appropriate tool (syntax_tools) on checkout/commit.
> Each user could have any presentation they wanted. If you like your
> ';' before the case clause you get that style 'cause that's what your
> tools are configured for. All style debates would be ended.

This would be the ideal solution. However it requires that ALL tools
know haw to handle this, including for example github or another
cloud-based source code handling tool. Also, this assumes that all
code that is checked in is parseable, which is not always the case.

> On Wed, Feb 05, 2014 at 09:27:35PM +0100, Vlad Dumitrescu wrote:
> } Absolutely, this would fix it. But we don't have tools that can handle
> } that yet and I fear that implementing those and convincing people to
> } use them would take longer than agreeing on a saner alternative for
> } whitespace.
>
> When I first suggested this I was quickly reminded that all preprocessor
> information would be lost. There would be no macros and no comments.
>
> But didn't you solve that problem in Erlide Vlad? I remember looking
> and seeing where you were doing preservation of macros and comments
> when working with abstract syntax.

Yes, we have to use a scanner/parser that exactly mirrors the
structure of the code as written, with comments and macros. The
assumption is that the macros are well-behaved, which isn't always
true. Not even the OTP code was free of such macros last time I
checked (R15, I think), but at least now the ?line macros have been
deprecated.

If a scanner/parser is used only to mirror the structure of the code,
then it's possible to implement it relatively easy. If the resulting
tree has to match the structure of the code after macro expansion too,
then it's not possible in the general case. The latter applies to
erlide, where we need to feed the code structure to other tools, so we
are only doing it in "best effort" style and there's still more work
to do.

regards,
Vlad

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

Thank you for the clarification. I agree, if a formatter started to
format inside strings then it could introduce bugs. Any tool (say a
compiler) that does that kind of changes would be dangerous. It would be
a bug, but still a problem.


bengt

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

Does your "erl-indent" program format according to the current OTP style
guide? It would be very good if that was the case.


bengt

[Vlad Dumitrescu]

On 6 Feb 2014 12:27, "Bengt Kleberg" <bengt....@ericsson.com> wrote:
>
> Greetings,
>
> These are my opinions, not facts.
>
> Does your "erl-indent" program format according to the current OTP style
> guide? It would be very good if that was the case.

It uses erlang - mode to indent. I certainly assume that it uses the style recommended by otp.

Not all otp source files are idempotent under the indentation, so it might mean that not all are following the otp style.

/vlad

[Andrzej Śliwa]

Here is my script for re-indent: https://github.com/andrzejsliwa/vimfiles/blob/master/emacs_indent.sh

I used it before switch to Emacs.

it also using emacs in batch mode, and trying guess correct path to emacs-mode (for linux and macosx)

this script was base for reformat in intellij-erlang for emacs way formatting.

Best Regards,

Andrzej

[Anthony Ramine]

I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard.

--
Anthony Ramine

Le 6 févr. 2014 à 08:19, Bengt Kleberg <bengt....@ericsson.com> a écrit :

> The editors I use have a way to change the size of a tabstop. The word
> processors I use have a way to change the size of each tabstop level. If
> 8 was the correct number these possibilities would not be present.

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

It is strange that you hate tabs when it is the tools that are doing it
wrong. Please try to not kill the messenger...


bengt

On Thu, 2014-02-06 at 13:29 +0100, Anthony Ramine wrote:
> I hate tabs because tools without settings, and default settings of most historical tools, render tabs with 8 spaces. Thus this is the de facto standard.
>

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 1:43 PM, Bengt Kleberg <bengt....@ericsson.com> wrote:

Greetings,

These are my opinions, not facts.

It is strange that you hate tabs when it is the tools that are doing it
wrong. Please try to not kill the messenger...

starting to be horribly annoyed by your top post that force me to read the context and your header

""'

Greetings,

These are my opinions, not facts.

"""

please answer in the context or give the context in your top post...

- benoit

 

[Anthony Ramine]

We can’t use tabs for indentation in Erlang because indentation in Erlang is not fixed.

I’m now out of this debate because this constant « These are my opinions, not facts. » is driving me insane.

--
Anthony Ramine

[Bengt Kleberg]

Greetings,

These are my opinions, not facts.

"erl-indent" can only be used on the OTP files that follow the style
guide they recommend. Even if that is just a few it is better than the
current cut-and-paste of tabs and spaces that I have to do in all files.
Thank you for the tool.


bengt

[Loïc Hoguin]

Don't try to squeeze a top/bottom posting holy war in the middle of a
tabs vs space debate!

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
http://ninenines.eu

[Bengt Kleberg]

---

From: Benoit Chesneau [bche...@gmail.com]
Sent: Thursday, 06 February 2014 1:46 PM
To: Bengt Kleberg
Cc: erlang-questions
Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation

Greetings,

It is unfortunate that you do not find enough context in my post. I strive to give it. Could you be so kind and elaborate what I missed out when I wrote the context "It is strange that you hate tabs when it is the tools that are doing it wrong." ?

As to why  I do not answer in context I can explain. I take "in the context" to mean inserting spurious lines here and there through out the original email. A very bad experience of that have put me off. The writer would edit the original email, removing things he deemed unimportant, and then answer the resulting mess as unhelpfully as possible. The helpfulness sort of made sense given how badly mangled the original email had become. Unpleasant.

However, now that the only person ever to become upset enough to actually write to me about how I write opinions as if they are facts, has decided that it is even worse to have to read that my opinions are my opinions, I will stop doing that.


bengt

[Bengt Kleberg]

Greetings,

If you are driven insane when I write that my opinions are my opinions, and you are sufficiently angered to write me about it when I do not make such a claim, I do not see how I can make you happy.
I will go back to how I used to do it before.

Sorry to say I do not understand how your statement "indention in Erlang is not fixed" rules out using tabs for indention. Can tabs only be used when indention is fixed? Fixed to what?


bengt
________________________________________
From: Anthony Ramine [n.o...@gmail.com]
Sent: Thursday, 06 February 2014 1:47 PM

To: Bengt Kleberg
Cc: erlang-questions
Subject: Re: [erlang-questions] Controversial subject of the day: tabs and spaces for indentation

[Garrett Smith]

This has been a very productive thread. If I may try to summarize, for
posterity:

- Mixed tabs and spaces present challenges for programmer using
different editors and contributing to projects with varied or poorly
defined white space standards

- There are a number of possible solutions to this problem, many of
which have been mentioned here

- The cost of discussing this problem is so much higher than cost of
actually dealing with it - even in cases where a programmer has to
manually copy and past formatted lines to preserve a source file's
dark, twisted and immortal formatting - it's *still much easier* than
talking about how to fix the underlying problem

I feel a certain liberation knowing this.

These are my opinions, which are facts.

Garrett

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 5:02 PM, Garrett Smith <g...@rre.tt> wrote:

This has been a very productive thread. If I may try to summarize, for
posterity:

- Mixed tabs and spaces present challenges for programmer using
different editors and contributing to projects with varied or poorly
defined white space standards

- There are a number of possible solutions to this problem, many of
which have been mentioned here

- The cost of discussing this problem is so much higher than cost of
actually dealing with it - even in cases where a programmer has to
manually copy and past formatted lines to preserve a source file's
dark, twisted and immortal formatting - it's *still much easier* than
talking about how to fix the underlying problem

I feel a certain liberation knowing this.

These are my opinions, which are facts.

I learnt today that I hate any opinions which are facts. This is a fact.

- benoit

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 5:12 PM, Benoit Chesneau <bche...@gmail.com> wrote:

I learnt today that I hate any opinions which are facts. This is a fact.

+ not 

[Gianfranco Alongi]

Please, as fun as this is, try to respect the reason for the mail list and have in mind that people may be subscribed to different lists.

It should not be necessary to clear out mail list messages because they are of topic and not add anything to any Erlang related discussion.

[Andrzej Śliwa]

I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them. 

Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear.

I really enjoy approach of “let it fail” also in real life… with respect to giving somebody chance to change his mind later.

I think there is no space in discussions for “hate” feelings… we could unlike opinions, not agree with them, but I think “hate" is really to strong statement.

  

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 5:29 PM, Benoit Chesneau <bche...@gmail.com> wrote:

> On Thu, Feb 6, 2014 at 5:24 PM, Andrzej Śliwa <andrze...@i-tool.eu> wrote:
>>
>> I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them.
>> Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear.
>>
>> I really enjoy approach of “let it fail” also in real life… with respect to giving somebody chance to change his mind later.
>>
>> I think there is no space in discussions for “hate” feelings… we could unlike opinions, not agree with them, but I think “hate" is really to strong statement.
>
>

> hate: a very strong feeling of dislike
>
> This exactly what I wanted to express.
>

Also if you if you missed the "not", It was attached to facts. And was
a blink. But you failed to understand it locked in your politically
correctness trap.

- benoit.

[Benoit Chesneau]

On Thu, Feb 6, 2014 at 5:24 PM, Andrzej Śliwa <andrze...@i-tool.eu> wrote:
>

> I know that discussions sometimes are really hard but we should respect other opinions even if we not agree with them.
> Everybody have full right to keeps own opinion and also should respect others points of view. The good arguments in dicussions are something which I love to hear.
>
> I really enjoy approach of “let it fail” also in real life… with respect to giving somebody chance to change his mind later.
>
> I think there is no space in discussions for “hate” feelings… we could unlike opinions, not agree with them, but I think “hate" is really to strong statement.

hate: a very strong feeling of dislike

This exactly what I wanted to express.

- benoit

[Richard A. O'Keefe]

On 6/02/2014, at 8:36 PM, Bengt Kleberg wrote:
> The use of one tab for one level of indention is logical. The indention
> level is 1, so why have another amount of characters? The only reason I
> have heard for X =/= 1 is that 1 space is too narrow. So, use 1 tab. All
> editors that I use can make 1 tab take up whatever width I like for
> indentation.

Sadly, there are tools other than editors.
Having to hunt them down, trying to reconfigure them ALL,
and failing, is why I refuse to mess with the defaults.

Sadly, there are more editors out there than vi(m) and (x)emacs,
and they do not all understand each other's way of recording the
tab width. (Did anyone out there ever have to deal with code
written using VED? Or Macintosh editors that kept info like that
in resource forks?)

I owe you people a debt of thanks.
My text editor now has a quick-and-easy "untabify buffer" command.
I wouldn't have bothered without this thread.

[Richard A. O'Keefe]

On 6/02/2014, at 9:21 AM, kraythe . wrote:

> Actually the solution to this age old debate was proposed to me by a friend of mine and its genius on a number of levels but isn't implemented anywhere. The reality is that for most languages whitespace is irrelevant so it shouldn't be the code holding the indentation but the user's preference file. Imagine a source code repository where there is NO irrelevant whitespace in the code base. For java, for example, there would be literally only one single line of code. Now when you check out you have a preference file that says you want tabs or spaces or mixed and also defines the other formatting you prefer. When you check out the system reformats the code according to your specs dynamically. When you commit, it strips your code of whitespace before comparing.

The IDE I use on the rare occasions that I write C# does
something not entirely unlike that. There is a bunch of
flags you can set; each comes with an example for each
alternative and you pick the one you want. It then shows
you the source code in the style you like. I have no idea
how it does this.

Of course there are languages (Occam, Haskell, Clean, Python,
...) where leading white space _does_ matter, and there are
plenty of languages (Fortran, C, APL, AWK, ...) where line
breaks matter a lot.

I suppose I can mention Interlisp-D again?
An idea that had the Xerox PARC people jumping up and down
and hugging themselves in the 80s was

A program is not a listing

it's a data base.

Source code was saved in files that were sort of readable,
but the system built indices and didn't necessarily read
them from beginning to end. Come to think of it, Smalltalk
keeps the source code on disc as a base data base + a log of
changes, keeps changes as a data structure internally, and
can be set to reindent the source code before showing it to
you (and note that this is not, per se, a change). Even the
ANSI standard format for Smalltalk source code is not really
meant for people to read and write, and as for SIXX, ...

This isn't quite the same as the proposal above, because
these systems _did_ keep white space in the data base that
wasn't strictly necessary, but they didn't/don't _depend_
on it for what they show you.

Of course this is *wonderful*, but only as long as the only
tools you want to use are the ones built into the IDE or
readily scriptable in it. Interlisp was/Smalltalk is good
at navel-gazing, but each Smalltalk is, *sigh*, different...

[Bengt Kleberg]

Greetings,

Would it be correct to say that this solution trades the possibilities
of user configurable tab width when available, for the certainty of
being able to use even those programs that have a hard coded tab width?


bengt

[Bengt Kleberg]

Greetings,

I think you have a correct thread summary here below.

Perhaps the thing that Lukas mentioned, ie that any formatter must be good enough top not introduce bugs, should also be added?

And maybe Rickards (later) email about the need to set tabs to the right amount of spaces, when it is configurable, if you need to use programs that have the tab width hard coded?


bengt
________________________________________
From: Garrett Smith [g...@rre.tt]
Sent: Thursday, 06 February 2014 5:02 PM

[Jarimatti Valkonen]

Richard A. O'Keefe <o...@cs.otago.ac.nz> kirjoitti 7.2.2014 kello 7.10:

> I suppose I can mention Interlisp-D again?
> An idea that had the Xerox PARC people jumping up and down
> and hugging themselves in the 80s was
>
> A program is not a listing
>
> it's a data base.
>
>

[snip]

> Of course this is *wonderful*, but only as long as the only
> tools you want to use are the ones built into the IDE or
> readily scriptable in it. Interlisp was/Smalltalk is good
> at navel-gazing, but each Smalltalk is, *sigh*, different...

I've been having this idea in my head about something similar to a Smalltalk system browser, but for Erlang. Useful? I doubt it, but at least it would be an interesting experiment. A source editor is doable, but making it work on a live system is left as an exercise to the reader. :)

Is anyone aware of anything similar?

And yes, I don't see this solving the tab/space indentation discussion.

[Richard A. O'Keefe]

> ________________________________________
> From: Garrett Smith [g...@rre.tt]
> Sent: Thursday, 06 February 2014 5:02 PM

> - Mixed tabs and spaces present challenges for programmer using
> different editors and contributing to projects with varied or poorly
> defined white space standards

This is somewhat misleadingly phrased.
Tabs do this all by themselves.

For example, I once spent some time using a programming
language where the IDE on Macs insisted that tabs were
equivalent to 4 spaces and the Unix command line tools
insisted that tabs were and could only be equivalent to
8 spaces, AND the language was indentation-sensitive.

So remember, it's not "mixed tabs and spaces present
challenges", it's "tabs present challenges".

The fundamental problem is that by design, tabs have
no common meaning other than "some amount of horizontal
white space".

[Loïc Hoguin]

On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote:
>> - Mixed tabs and spaces present challenges for programmer using
>> different editors and contributing to projects with varied or poorly
>> defined white space standards
>
> This is somewhat misleadingly phrased.
> Tabs do this all by themselves.
>
> For example, I once spent some time using a programming
> language where the IDE on Macs insisted that tabs were
> equivalent to 4 spaces and the Unix command line tools
> insisted that tabs were and could only be equivalent to
> 8 spaces, AND the language was indentation-sensitive.
>
> So remember, it's not "mixed tabs and spaces present
> challenges", it's "tabs present challenges".

Tabs are perfectly fine for indentation. You had issues only because you
were doing both indentation *and* alignment. If you don't align your
code, it doesn't matter what the tab length is.

Just like the CAP theorem, I posit the TIA theorem: tabs, indentation,
alignment, choose two.

--
Loïc Hoguin
http://ninenines.eu

[Fred Hebert]

The best part of your conjecture is that we can forget about tabs
entirely and still have everything working fine.

Sounds like a good deal.

Regards,
Fred.

[Anthony Ramine]

Erlang/OTP already chose indentation and alignment:

move_case_into_arg(#c_case{arg=#c_case{arg=OuterArg,
clauses=[OuterCa0,OuterCb]}=Outer,
clauses=InnerClauses}=Inner0, Sub) ->
case is_failing_clause(OuterCb) of
true ->
#c_clause{pats=OuterPats0,guard=OuterGuard0,
body=InnerArg0} = OuterCa0,
%%
%% case case <OuterArg> of
%% <OuterPats> when <OuterGuard> -> <InnerArg>
%% <OuterCb>
%% ...
%% end of
%% <InnerClauses>
%% end
%%
%% ==>
%%
%% case <OuterArg> of
%% <OuterPats> when <OuterGuard> ->
%% case <InnerArg> of <InnerClauses> end
%% <OuterCb>
%% end
%%
ScopeSub0 = sub_subst_scope(Sub#sub{t=[]}),
{OuterPats,ScopeSub} = pattern_list(OuterPats0, ScopeSub0),
OuterGuard = guard(OuterGuard0, ScopeSub),
InnerArg = body(InnerArg0, ScopeSub),
Inner = Inner0#c_case{arg=InnerArg,clauses=InnerClauses},
OuterCa = OuterCa0#c_clause{pats=OuterPats,guard=OuterGuard,
body=Inner},
Outer#c_case{arg=OuterArg,
clauses=[OuterCa,OuterCb]};
false ->
impossible
end;

Following your TIA theorem, tabs need to go.

--
Anthony Ramine

[Geoff Cant]

On 2014-02-10, at 14:12 , Loïc Hoguin <es...@ninenines.eu> wrote:

> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote:
>>> - Mixed tabs and spaces present challenges for programmer using
>>> different editors and contributing to projects with varied or poorly
>>> defined white space standards
>>
>> This is somewhat misleadingly phrased.
>> Tabs do this all by themselves.
>>
>> For example, I once spent some time using a programming
>> language where the IDE on Macs insisted that tabs were
>> equivalent to 4 spaces and the Unix command line tools
>> insisted that tabs were and could only be equivalent to
>> 8 spaces, AND the language was indentation-sensitive.
>>
>> So remember, it's not "mixed tabs and spaces present
>> challenges", it's "tabs present challenges".
>
> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is.
>
> Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two.
>

Is there an argument in favour of jettisoning alignment in favour of tabs?

I favour alignment over tabs, and am happy to work on other people's code no matter how many spaces they want for indentation[1]. I have never once been glad that tabs-in-code let me choose my own indent level when viewing it - alignment has always been preferable as a mechanism for making code more readable.

Opinionatedly,
--
Geoff
[1] If you pick 16, that's cool - I'll probably just fork your library.

[Richard A. O'Keefe]

On 7/02/2014, at 8:39 PM, Jarimatti Valkonen wrote:
> I've been having this idea in my head about something similar to a Smalltalk system browser, but for Erlang. Useful? I doubt it, but at least it would be an interesting experiment. A source editor is doable, but making it work on a live system is left as an exercise to the reader. :)

I had the same idea about Prolog at one point.

For the benefit of people who haven't used Smalltalk,
the basic browser interface is the "five pane browser".

+---------+---------+---------+---------+
|list of |list of |list of |list of |
|groups of|classes |groups of|methods |
|classes |in group |methods |in group |
+---------+---------+---------+---------+
|a bunch of buttons |
+---------------------------------------+
|edit window for class description |
|or class comment |
|or method definition |
|or for showing output of a tool such |
|as a lint checker |
| |
+---------------------------------------+

A "class category" is roughly like an application in Erlang.
A "class" is roughly like a module in Erlang.
A "method category" is a named group of semantically
related functions, e.g., methods for comparing, methods
for printing, methods for iteration, &c.
A "method" is roughly speaking a named function.

There are several more or less specialised versions of this
and you can have any number of them on screen tat the same
time.

Modern Smalltalks also have things we might call "package
browsers" and/or "repository browsers" for locating,
inspecting, and possibly installing add-on packages that
are not loaded by default and might be held remotely.

The "class categories" and "method categories" are
programmer-selected names for groups of things that
are managed by the programmer. These properties are
available for query (and update!) by running code,
but have no other effect on execution semantics.
Methods may be further classified semantically by adding
"pragmas" to their source; this may be reflected in the
way the method's name is display, and is accessible as
run-time data.

This is a really good way to get to know an unfamiliar
class one method or one facet (method category) at a
time. It can be a pain in the backside when you are
trying to understand the interactions of several methods
at once.

It can also be a bit awkward when you are trying to
ensure that the definitions of a method in several classes
are semantically consistent; then you want to slice by
method rather than class. Fortunately, Smalltalk IDEs
often have some sort of "method finder" that lets you
find/pick a particular method name and get a list of all
the classes that implement it. (It is really annoying the
way VW closes that list as soon as you pick one element.
Squeak gets that right.)

I think perhaps there are two key ideas that could be
adapted to the Erlang world:

- programmer defined indexing terms for modules and
for functions, so you could say "what are some
modules or functions that are *about* this topic"
whatever they might be named.

Perhaps
-index([ List of strings ]).
before the first -export: relating to the module;
after the last function: relating to the module;
elsewhere: relating to the next function.

- having multiple ways of viewing the code base,
slicing by module or function or data type or whatever.


elsewhere:
E

[Richard A. O'Keefe]

On 11/02/2014, at 11:12 AM, Loïc Hoguin wrote:

> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote:
>>
>> So remember, it's not "mixed tabs and spaces present
>> challenges", it's "tabs present challenges".
>
> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is.

To the limited extent that I understand the distinction you are
making between "indentation" and "alignment", I don't understand it.
To me, indentation simply *is* "making some aspect of structure
directly visible by mapping nesting depth to distance from the
left margin".

A 'character' which corresponds to an unpredictable and uncontrollable
amount of white space simply isn't up to the job. (Yes, if you put an
Emacs mode line into a file, tab width *is* predictable and controllable
for that file, BUT ONLY IN Emacs.) If you mean that the indentation
will be *logically* correct as far as a parser is concerned, fine.
But it won't be *visually* correct.

By the way, the IDE didn't, for all practical purposes, offer me any
choice in the matter.

[Loïc Hoguin]

On 02/10/2014 11:22 PM, Geoff Cant wrote:
> On 2014-02-10, at 14:12 , Loïc Hoguin <es...@ninenines.eu> wrote:
>
>> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote:
>>>> - Mixed tabs and spaces present challenges for programmer using
>>>> different editors and contributing to projects with varied or poorly
>>>> defined white space standards
>>>
>>> This is somewhat misleadingly phrased.
>>> Tabs do this all by themselves.
>>>
>>> For example, I once spent some time using a programming
>>> language where the IDE on Macs insisted that tabs were
>>> equivalent to 4 spaces and the Unix command line tools
>>> insisted that tabs were and could only be equivalent to
>>> 8 spaces, AND the language was indentation-sensitive.
>>>
>>> So remember, it's not "mixed tabs and spaces present
>>> challenges", it's "tabs present challenges".
>>
>> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is.
>>
>> Just like the CAP theorem, I posit the TIA theorem: tabs, indentation, alignment, choose two.
>>
>
> Is there an argument in favour of jettisoning alignment in favour of tabs?
>
> I favour alignment over tabs, and am happy to work on other people's code no matter how many spaces they want for indentation[1]. I have never once been glad that tabs-in-code let me choose my own indent level when viewing it - alignment has always been preferable as a mechanism for making code more readable.

One day not too long ago I decided to stop aligning entirely. Code is
still as readable as before, and I don't have to spend any time worrying
about prettifying the code (or fixing what the auto identation thing
did). Nobody said my code is less readable because of it so far.

I'm using tabs mostly for historical reasons, if I were to use spaces I
still wouldn't align.

--
Loïc Hoguin
http://ninenines.eu

[Loïc Hoguin]

On 02/11/2014 12:00 AM, Richard A. O'Keefe wrote:
>
> On 11/02/2014, at 11:12 AM, Loïc Hoguin wrote:
>
>> On 02/10/2014 11:01 PM, Richard A. O'Keefe wrote:
>>>
>>> So remember, it's not "mixed tabs and spaces present
>>> challenges", it's "tabs present challenges".
>>
>> Tabs are perfectly fine for indentation. You had issues only because you were doing both indentation *and* alignment. If you don't align your code, it doesn't matter what the tab length is.
>
> To the limited extent that I understand the distinction you are
> making between "indentation" and "alignment", I don't understand it.
> To me, indentation simply *is* "making some aspect of structure
> directly visible by mapping nesting depth to distance from the
> left margin".

Indentation:

myfunction(A, B, C,
D, E) ->

Alignment:

myfunction(A, B, C,
D, E) ->

But also, skipping the indentation that would be to the left of these
assignments...

No alignment:

A = 1,
Bartender = 17,
Car = 35,

Alignment:

A = 1,
Bartender = 17,
Car = 35,

Hopefully it'll show up properly in the email.

--
Loïc Hoguin
http://ninenines.eu

[Richard A. O'Keefe]

On 11/02/2014, at 12:09 PM, Loïc Hoguin wrote:
>
> One day not too long ago I decided to stop aligning entirely. Code is still as readable as before, and I don't have to spend any time worrying about prettifying the code (or fixing what the auto identation thing did). Nobody said my code is less readable because of it so far.

Can you explain what you mean by "aligning"?

[Richard A. O'Keefe]

Our message crossed.

On 11/02/2014, at 12:13 PM, Loïc Hoguin wrote:
>
> Indentation:
>
> myfunction(A, B, C,
> D, E) ->
>
> Alignment:
>
> myfunction(A, B, C,
> D, E) ->

I don't call that "alignment", I call that "evil".
As far as I am concerned, one of the core rules of
good indentation is
- the presence or absence of line breaks will
depend on the size of names and constants
- but the AMOUNT of indentation never will.

Why? Because indentation is supposed to reveal
STRUCTURE, not spelling.

I would write this as

my_function(
A, B, C, D, E
) ->

I know Lisp has traditionally used this style,
but I decided decades ago that it was wrong,
and I've never regretted it.

> But also, skipping the indentation that would be to the left of these assignments...
>
> No alignment:
>
> A = 1,
> Bartender = 17,
> Car = 35,
>
> Alignment:
>
> A = 1,
> Bartender = 17,
> Car = 35,

This I _do_ align, sometimes. It's not a case where I would
ever have found tabs useful anyway.

I also try to align blocks of related end-of-line comments
so they start in the same column. For that I used to use
tabs, but found it a pain.

[Bengt Kleberg]

Greetings,

Is it not difficult to preserve alignment when using both variable width
characters and fixed width characters tools?


bengt

[Anthony Ramine]

No need to mix anything, it is hard to preserve in presence of any tab.

--
Anthony Ramine

[Bengt Kleberg]

Greetings,

I thought more of aligning difficulties given variable width characters
and fixed width characters in different programs/tools. No tabs
included.


bengt

On Tue, 2014-02-11 at 10:20 +0100, Anthony Ramine wrote:
> No need to mix anything, it is hard to preserve in presence of any
> tab.
>
> --
> Anthony Ramine
>
> Le 11 févr. 2014 à 07:16, Bengt Kleberg <bengt....@ericsson.com> a
> écrit :
>
> > Greetings,
> >
> > Is it not difficult to preserve alignment when using both variable
> width
> > characters and fixed width characters tools?
> >
> >
> > bengt

[Loïc Hoguin]

Alignment is *impossible* with fonts with variable width characters. And
a few editors have such a font by default. That's a good point. If you
do alignment, then your code will look bad for some people.

--
Loïc Hoguin
http://ninenines.eu

[Loïc Hoguin]

On 02/11/2014 02:17 AM, Richard A. O'Keefe wrote:
> Our message crossed.
>
> On 11/02/2014, at 12:13 PM, Loïc Hoguin wrote:
>>
>> Indentation:
>>
>> myfunction(A, B, C,
>> D, E) ->
>>
>> Alignment:
>>
>> myfunction(A, B, C,
>> D, E) ->
>
> I don't call that "alignment", I call that "evil".
> As far as I am concerned, one of the core rules of
> good indentation is
> - the presence or absence of line breaks will
> depend on the size of names and constants
> - but the AMOUNT of indentation never will.
>
> Why? Because indentation is supposed to reveal
> STRUCTURE, not spelling.

I agree. Unfortunately many people align there.

> I would write this as
>
> my_function(
> A, B, C, D, E
> ) ->

That certainly looks better.