Re: [Tracker] Whitespace clean up

[Martyn Russell <martyn lanedo com>]

On 08/12/09 12:12, Philip Van Hoof wrote:
> On Tue, 2009-12-08 at 09:50 +0000, Martyn Russell wrote:

> Note that this means that ALL whitespace involved in the alignment
> should be spaces. Not just the last few ones.

Yea, I agee, however, I wonder how to do this in Emacs. I need to check.

> Not this:
>
> void
> host (void) {
> \tfunction (parameter1,
> \t\t\t\t....parameter2)
> }
>
> But this:
>
> void
> host (void) {
> \tfunction (parameter1,
> \t..........parameter2)
> }

Yea.

> This also works recursive:
>
> void
> host (void) {
> \tfunction (parameter1,
> \t..........another_function (par1,
> \t............................par2),
> \t..........parameter2)
> }
>
> It also means ALL whitespace (I repeat but, this is another example):
>
> This this:

I presume you mean s/This/Not/ :)

> void
> my_very_long_function_name (MyType\t..*varname1,
> ...........................(MyType\t..*varname2)
> {
> }

This is actually the one thing that annoys me right now with the 
alignments in Tracker and it all gets broken when the function name 
changes or variables change slightly.

I think I used Emacs to do the alignment initially so I would probably 
look into using a better tool to do this.

> But this:
>
>
> void
> my_very_long_function_name (MyType...*varname1,
> ...........................(MyType...*varname2)
> {
> }

I agree.

> > I would like to try to make sure this is the case in the code and at the
>
> I would strongly recommend against going over all lines of code and
> starting to change whitespace everywhere.
>
> Instead work on the module that you're changing for a feature. For
> example:


> 1) Before you start with your feature, do a whitespace clean. Commit.
> 2) Implement the feature, with right whitespace use. Commit.
> 3) Push to git

We should be doing this anyway, yes. Actually, I would like some git 
pre-commit script to disallow commits with whitespace problems if possible.

We should look into that.

> I don't think it's helpful if somebody makes huge massive commits that
> change the whitespace in all files in one big commit. It'll actually
> make development, history, etc quite a horror.

As discussed on IRC, this is less problematic with git blame if you use 
the -w switch (to ignore whitespace changes). I think git blame was the 
main use case that would be problematic.

> Please discuss this first on #tracker with JÃrg, Carlos, me, Ivan and
> Ottela.

Done.

> > same time remove any trailing white space. Choosing the right time for
> > this is important too because we have some branches which are likely to
> > have merge conflicts.
>
> > Currently active non-merged branches:
> >
> >     mmc
> >     miner-web
> >     msword
> >     nautilus-extension
> >     nmo
> >     quad
> >     subqueries

So of these branches, we discussed on IRC, it looks like miner-web might 
suffer but the rest should be already merged or minor to fix.

> > When makes sense to make these changes?
>
> Gradually makes sense. The sudden big commit doesn't make sense to me.

Again, as discussed on IRC, we can do this in one commit (perhaps this 
week).

--
Regards,
Martyn