Signed-off-by: Josh Triplett <josh@kernel.org>
---
 Documentation/CodingStyle |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index b49b92e..00bffa7 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -218,6 +218,18 @@ no space after the prefix increment & decrement unary operators:
 
 and no space around the '.' and "->" structure member operators.
 
+Do not leave trailing whitespace at the ends of lines.  Some editors with
+"smart" indentation will insert whitespace at the beginning of new lines as
+appropriate, so you can start typing the next line of code right away.
+However, some such editors do not remove the whitespace if you end up not
+putting a line of code there, such as if you leave a blank line.  As a result,
+you end up with lines containing trailing whitespace.
+
+Git will warn you about patches that introduce trailing whitespace, and can
+optionally strip the trailing whitespace for you; however, if applying a series
+of patches, this may make later patches in the series fail by changing their
+context lines.
+
 
 		Chapter 4: Naming
 
-- 
1.5.2.1


-

[ message continues ]

What I'd really like to see is, _why_ is trailing whitespace
considered harmful?  Something about MUAs not preserving it or
something?

-chris
-

[ message continues ]

When the trailing whitespace later disappears, that change shows up in
diffs, and since you can't see the whitespace difference, it just looks
like a mysterious change until you check it more closely.  It also
introduces gratuitous conflicts and other such annoyances.

- Josh Triplett


-

[ message continues ]

Okay, but it seems like this is more of an argument that diffs
containing lines that change only the trailing whitespace are
considered harmful.  I buy that, but I don't see why it follows that

I don't get this part.  Only changes can create conflicts.  Are there
some editors (or MUAs) that change trailing whitespace without being
told to?  (And I'm not even talking about your warning about conflicts
created by applying stripped versions of early patches in a series -
that's just self-inflicted pain.)

-chris
-

[ message continues ]

Well, there is format=flowed. text/plain mails with a trailing blank at the end
of line indicates the paragraph continues -- as a curtesy for mail readers with
non-fixed-font to display the paragraph coherently rather than breaking it at
72/80 columns.


	Jan
-- 
-

[ message continues ]

There's more potential to cause  lines end with whitespace. How about
remove the "Some editors with ..."  like this :

+Do not leave trailing whitespace at the ends of lines.
+
+Git will warn you about patches that introduce trailing whitespace, and can
+optionally strip the trailing whitespace for you; however, if applying a series
+of patches, this may make later patches in the series fail by changing their
+context lines.
+
-

[ message continues ]

[...]

Many other causes for trailing whitespace exist.  However, I wanted to mention
one of the common causes.  If you have other common causes in mind, and even
better if you have ways to avoid them, we should add those too.

It might make sense to put a paragraph break after the first sentence, though,
and split the information about editors into its own paragraph, adding more
paragraphs if people suggest other possibilities.

- Josh Triplett
-

[ message continues ]

IMHO, another  cause of trailing whitespace is human error, for
example long lines breaking will easy to cause the first line with one
traling whitespace (original space between the last two words).

Regards
dave
-

[ message continues ]

Most common errors (to me) are:

 - hit return+tab too quickly that it interchanges, hence producing
   the unwanted \t\n
 - hit return+return to start a new paragraph of code;
   the intermediate line remains indented if autoindent is on.


	Jan
-- 
-

[ message continues ]

Interestingly, emacs gets that case right: when you hit enter it places the
cursor at the properly indented insertion point, but if you leave the line
without typing anything it does not leave the indentation.  I thought I
remembered vim doing the same thing, but I just tested and it appears not.  It
seems to avoid leaving subsequent lines indented, but not the first one.

- Josh Triplett

-

[ message continues ]

one.

No, vim works just fine here without leaving any indentation.  Maybe the
version of vim or the options matter.

- Leo
-

[ message continues ]

Yes, vim autoindent doesn't leave tabs in blank line for me.
-

[ message continues ]

And for vim trailing space, there's a tip in vim.org:
http://www.vim.org/tips/tip.php?tip_id=878
-

[ message continues ]

I actually prefer this (in .vimrc):

" Show trailing whitespace and spaces before tabs
hi link localWhitespaceError Error
au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display
au Syntax * syn match localWhitespaceError / \+\ze\t/ display

It always displays trailing whitespace and spaces-before tabs...  
except if your cursor is at the end of the whitespace.  The updating  
is occasionally a bit laggy (EG: Put spaces on a line and then move  
the cursor off it without pressing <ENTER>), but when you hit Ctrl-L,  
enter, or edit an adjacent line then it updates.

The script mentioned there *is* good for removing said whitespace,  
though

Cheers,
Kyle Moffett

-

[ message continues ]

I prefer this:

find . -type f -print0 | xargs -0 grep -Pn '[\t ]+$'

It is editor agnostic, and I do not have to look through all source files for

	Jan
-- 
-

[ message continues ]

And if you really want highlighting, you can always use grep --color. :)

- Josh Triplett

-

[ message continues ]

Been there, done that, have GREP_COLOR env variable defined!


	Jan
-- 
-

[ message continues ]

Same here.  Now I just need to convince git-grep to use it.

- Josh Triplett

-

[ message continues ]

You need to convince grep. When piping its output to less, it won't
colorize unless forced. Always forcing color via GREP_OPTIONS might
break certain use-cases, and git-grep doesn't allow to pass options. So
for me, a bash alias it is:

alias gg='GREP_OPTIONS=--color=always git-grep'

You might need to set LESS=-R in addition to that, to stop less from
stripping the color codes.

Björn
-

[ message continues ]

I ussualy prefer the simple vim search command:
/\ *$
-

[ message continues ]

Stolen from an old message in LKML - I don't remember who's the author:

highlight WhitespaceEOL ctermbg=red guibg=red
match WhitespaceEOL /\s\+$/

Works without any glitches here (not "laggy").  But I don't use
syntax coloring - never tried if it works with coloring or not.

/mjt
-

[ message continues ]

That only highlights whitespace at the end of the lines. You might
want to use pattern below to also highlight "tab after space" in the

-- 
Dmitry
-

[ message continues ]

You missed the nice part about my vimrc patterns: :-D


They intentionally *don't* display whitespace at the end of the line  
to the left of your cursor.  I tried that one (that you quoted), but  
got annoyed by the fact that immediately after you typed any space or  
tab you had a little red blob to the left of the cursor.  So some of  
that "lagginess" is intentionaly (although not all of it, due to vim  
limitations).

Cheers,
Kyle Moffett
-

[ message continues ]

I've previously found that vim's "cindent" mode is better than
"smartindent", which is better than "autoindent".  However, as of vim
6.3 autoindent seems to be fairly well off; the following does TRT:
`int SPC foo() RET { RET C-t int SPC x; RET RET foo(); RET'
(leaving an empty line between "int x;" and "foo();").  However, the
following does leave a line matching /^ +$/ even in smartindent and
cindent modes:
`int SPC foo() RET { RET int SPC x; RET SPC BS bar(); RET'
that is, if you edit the autoindented line before leaving it blank, then
vim 6.3 will not remove the autoindent spaces when you leave the line.

-andy
-

[ message continues ]

On Wed, 27 Jun 2007 10:59:20 -0700

quilt has ways of detecting and/or correcting newly-added trailing
whitespace, but I don't know the details.

One could share the various scriptlets which detect and fix trailing
whitespace but I think this issue is getting less and less important
now, because most maintainers will zap the new whitespace prior to
merging.

<checks>

akpm:/usr/src/25> grep -l "^+.*[        ]$" patches/git-*.patch
patches/git-acpi.patch
patches/git-alsa.patch
patches/git-battery.patch
patches/git-cifs.patch
patches/git-drm.patch
patches/git-gfs2-nmw.patch
patches/git-hid.patch
patches/git-ipwireless_cs.patch
patches/git-ixgbe.patch
patches/git-kgdb.patch
patches/git-leds.patch
patches/git-libata-all.patch
patches/git-md-accel.patch
patches/git-netdev-all.patch
patches/git-newsetup.patch
patches/git-nfs.patch
patches/git-ocfs2.patch
patches/git-pciseg.patch
patches/git-qla3xxx.patch
patches/git-selinux.patch
patches/git-sym2.patch
patches/git-unionfs.patch
patches/git-watchdog.patch
patches/git-wireless.patch

damn.  Bunch of lamers.

But there's less than there used to be.
-

[ message continues ]

9. The editor is the primary tool for programmers. People who don't
       choose an appropriate primary tool are worthless as professionals.

among others in <http://quimby.gnus.org/circus/notes/programming.html>

I've shared little sh script too, 4 + 2(optional) sed commands with
comments of what whitespace crap was spotted. Yet nothing happened.
Converse -- questions about why they are useless...

Introduction of editor's labels in C files is the most outrages thing.
Don't editors smart to see filename extensions first? If they don't, fix
____
-

[ message continues ]

Upon `quilt ref`, it usually barfs about every line you touched where you

`| wc -l` it. The patches get larger, the # of patches declines :)


	Jan
-- 
-

[ message continues ]