What about feeding the code to RBConfigurableFormatter before merging so it matches the target style, and then there would be no need to worry about whitespace?

Also I have yet to see someone using spaces for indentation and trailing whitespace (empty lines included) is usually trimmed (but then again people do use different styles so it might not apply).

Peter

From: Jan Vrany
Sent: ��11/��20/��2014 2:38 PM
To: pharo-dev@lists.pharo.org
Subject: Re: [Pharo-dev] Source code formatting guidelines

Hi guys,

thanks for replies. I read books mentioned by Christophe years ago,
they're worth reading indeed.

But as I said, I'm more interested in 'low level' details like I
mentioned:
- tabs/spaces? How many spaces if spaces?
- encoding of the source string
- trailing newlines
- trailing spaces
- ...

The reason is I'm now working with Jan K. on some stuff and he's
using Pharo while I don't. To exchange code I read his .mcz when
merging his changes and generating .mcz for him when he has to merge
my stuff. However, Pharo's merge tool apparently does not do a
really great job when it comes to whitespace changes so the merge
is difficult and error-prone.
The idea is to transform the source just before spitting out the .mcz to
minimize these false-diffs when one try to merge.

Best, Jan

On Wed, 2014-11-19 at 15:19 +0100, Nicolai Hess wrote:
> 2014-11-19 14:55 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
>
>         > On 19 Nov 2014, at 14:47, Peter Uhn��k <i.uhnak@gmail.com>
>         > wrote:
>         >
>         >         how Pharo source code is formatted
>         > One could argue that this is equivalent to the default
>         > settings of Pharo formatter.
>
>         Which is not good�� e.g. it always adds too many line breaks��
>
>
>         Marcus
>
>
> If we can agree on source code guidelines, we should change the
> default settings of the Pharo formatter accordingly.
>