Extraneous whitespace removal?

Extraneous whitespace removal?

[Jeremy M. Dolan]

Well, I'll let the number speak:

$ cp -R linux-2.4.0 linux-2.4.0-trimed
$ find linux-2.4.0-trimed -type f | xargs perl -wi -pe 's/\s+$/\n/'
$ du -s linux-2.4.0 linux-2.4.0-trimed
119360  linux-2.4.0              # NOTE: 4k blocks, just an estimate
119160  linux-2.4.0-trimed

$ diff -ru linux-2.4.0 linux-2.4.0-trimed > trimed.diff
$ ls -l trimed.diff*
-rw-r--r--   1 jmd      users    19131225 Jan  8 01:49 trimed.diff
-rw-r--r--   1 jmd      users     4732306 Jan  8 01:50 trimed.diff.gz
-rw-r--r--   1 jmd      users     3819235 Jan  8 01:52 trimed.diff.bz2

Pluses:
 - clean up messy whitespace
 - cut precious picoseconds off compile time
 - cut kernel tree by 200k (+/- alot)

Minuses:
 - adds 3.8M bzip2 or 4.7M gzip to next diff

Notes:
 - Don't actually use the above perl s// command. Instead, use
   [<tab><space>] in place of the \s. The problem with \s is it
   includes page breaks. I only included this one since the one with
   tab isn't cut&paste-able.
 - I'm not yet positive there are no other places in the tree that
   aren't safe to s/[<tab><space>]+$//. C can, if formated poorly
   enough, be affected by it (multiline strings not ending with \).
   Can anyone very familiar with Makefile/DocBook/TeX/asm syntax
   comment if they could also be potentially affected?
 - Another place to save space is extraneous \n's before EOF. I think
   that saves an aditional 15k or so, based on rough estimates with
   grep.
 - Yes, I am pretty pedantic to propose a 19M patch that doesn't *DO*
   anything.
 
-- 
Jeremy M. Dolan <jmd@turbogeek.org>
OpenPGP key = http://turbogeek.org/openpgp-key
OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52  E0D5 5C5D 6228 DC43 3DEE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Extraneous whitespace removal?

[David Weinehall]

On Mon, Jan 08, 2001 at 04:42:18AM -0600, Jeremy M. Dolan wrote:

[snip]

>  - Yes, I am pretty pedantic to propose a 19M patch that doesn't *DO*
>    anything.

While I really like the idea with this patch, I'm 100% certain that
Linus would not, under any circumstances, accept this patch.

I suggest that we instead force everyone to program with:

syntax on
let c_space_errors=1

(Or equivalent Emacs/[insert favourite editor here]-setting instead)

While at it, force people to read linux/Documentation/CodingStyle
and make them adhere to it.

Of course, I guess this is a free world (yeah, right) and everyone
should have the right to code in their own way, but I'd wish that people
at least could be consistent when indenting/spacing/bracing/whatever,
and when patching other people's code, also follow the already set
standard of that file instead of introducing a new one...


/David Weinehall [yup, I know everyone will hate me for this...]
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Extraneous whitespace removal?

[Thomas Pornin]

In article <20010108044218.A9610@foozle.turbogeek.org> you write:
>  - I'm not yet positive there are no other places in the tree that
>    aren't safe to s/[<tab><space>]+$//. C can, if formated poorly
>    enough, be affected by it (multiline strings not ending with \).

Multiline strings not ending with \, are errors. gcc admits this
syntax but it is bad practice, and should be avoided.

For Makefile, DocBook, TeX and assembly, this should be ok too.

	--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Extraneous whitespace removal?

[Rusty Russell]

In message <20010108044218.A9610@foozle.turbogeek.org> you write:
> Pluses:
>  - clean up messy whitespace
>  - cut precious picoseconds off compile time
>  - cut kernel tree by 200k (+/- alot)

I've done this before, but never posted it, lest they think I'm
insane.  I vote this for 2.5.1.

You, sir, have balls,
Rusty.
--
http://linux.conf.au The Linux conference Australia needed.
--- working-2.4.0/MAINTAINERS.~1~	Mon Jan  1 04:31:15 2001
+++ working-2.4.0/MAINTAINERS	Tue Jan  9 11:23:48 2001
@@ -1434,6 +1434,11 @@
 L:	linux-scsi@vger.kernel.org
 S:	Maintained
 
+WHITESPACE
+P:	Jeremy M. Dolan
+M:	jmd@foozle.turbogeek.org
+S:	Maintained
+
 X.25 NETWORK LAYER
 P:	Henner Eisen
 M:	eis@baty.hanse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Extraneous whitespace removal?

[Wayne Scott]

From: Jeremy M. Dolan <jmd@turbogeek.org>
> Pluses:
>  - clean up messy whitespace
>  - cut precious picoseconds off compile time
>  - cut kernel tree by 200k (+/- alot)
>
> Minuses:
>  - adds 3.8M bzip2 or 4.7M gzip to next diff

As someone who has spend a lot of time working on version control and
file merging, let be tell you the big minus you missed. 

After this patch go into the Linux kernel, everyone who is maintaining
a set of patches in parallel with the main kernel has a lot of extra
work resolving the conflicts caused by this change.  You have touched
a huge number of lines and people will have to walk a list of merge
conflicts everywhere they have made local changes and pick their side.
And anytime people do a whole series of the same edits over and over
they will miss that real conflict in the middle and lose some
important change.

The other problem that occurs is for people who maintain version
histories.  It is really useful to know where (and why) a line was
last changed.  This obscures that information by a layer of edits that
made no change.

While saving a little space is nice, it is not worth the pain and risk
it involves.  I much prefer the solution suggested where incoming
patches are filtered before they are applied. Used consistantly, the
whitespace will be removed over time.

-Wayne

Re: Extraneous whitespace removal?

[Padraig Brady]

Wayne Scott wrote:

> From: Jeremy M. Dolan <jmd@turbogeek.org>
> 
>>Pluses:
>> - clean up messy whitespace
>> - cut precious picoseconds off compile time
>> - cut kernel tree by 200k (+/- alot)
>>
>>Minuses:
>> - adds 3.8M bzip2 or 4.7M gzip to next diff
>>
> 
> As someone who has spend a lot of time working on version control and
> file merging, let be tell you the big minus you missed. 
> 
> After this patch go into the Linux kernel, everyone who is maintaining
> a set of patches in parallel with the main kernel has a lot of extra
> work resolving the conflicts caused by this change.


Which is why 2.5.1 is the only time it can go in.
It would save 140K compressed (bz2) which kernel.org
would probably appreciate, but it's probably too late
already so the next best is always do it for subsequent patches.
Perhaps their should be a patch_pp script that does runs
both Lindent and strip_ws? Actually Alan Cox mentioned to
me that pine had a bug where it stripped whitespace at end
of lines :-) can't depend on that though.

Padraig.

Re: Extraneous whitespace removal?

[M. R. Brown]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

* Wayne Scott <wscott@bitmover.com> on Thu, Nov 29, 2001:

> From: Jeremy M. Dolan <jmd@turbogeek.org>
> > Pluses:
> >  - clean up messy whitespace
> >  - cut precious picoseconds off compile time
> >  - cut kernel tree by 200k (+/- alot)
> >
> > Minuses:
> >  - adds 3.8M bzip2 or 4.7M gzip to next diff
> 
> As someone who has spend a lot of time working on version control and
> file merging, let be tell you the big minus you missed. 
> 
> After this patch go into the Linux kernel, everyone who is maintaining
> a set of patches in parallel with the main kernel has a lot of extra
> work resolving the conflicts caused by this change.  You have touched
> a huge number of lines and people will have to walk a list of merge
> conflicts everywhere they have made local changes and pick their side.
> And anytime people do a whole series of the same edits over and over
> they will miss that real conflict in the middle and lose some
> important change.
> 

diff -w, diff -b, diff -B

M. R.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]