[PATCH] CodingStyle: Add information about trailing whitespace.

[PATCH] CodingStyle: Add information about trailing whitespace.

[Josh Triplett]

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Chris Shoemaker]

On Wed, Jun 27, 2007 at 10:59:20AM -0700, Josh Triplett wrote:
> +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.

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

-chris

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Josh Triplett]

On Wed, 2007-06-27 at 14:05 -0400, Chris Shoemaker wrote:
> On Wed, Jun 27, 2007 at 10:59:20AM -0700, Josh Triplett wrote:
> > +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.
> 
> What I'd really like to see is, _why_ is trailing whitespace
> considered harmful?  Something about MUAs not preserving it or
> something?

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Chris Shoemaker]

On Wed, Jun 27, 2007 at 11:17:09AM -0700, Josh Triplett wrote:
> On Wed, 2007-06-27 at 14:05 -0400, Chris Shoemaker wrote:
> > On Wed, Jun 27, 2007 at 10:59:20AM -0700, Josh Triplett wrote:
> > > +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.
> > 
> > What I'd really like to see is, _why_ is trailing whitespace
> > considered harmful?  Something about MUAs not preserving it or
> > something?
> 
> 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.  

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
new code shouldn't have any trailing whitespace at all.

> It also introduces gratuitous conflicts and other such annoyances.

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Jan Engelhardt]

On Jun 27 2007 14:05, Chris Shoemaker wrote:
>
>What I'd really like to see is, _why_ is trailing whitespace
>considered harmful?

Consumes bytes you'll never see :)

>Something about MUAs not preserving it or something?

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
-- 

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[dave young]

2007/6/27, Jan Engelhardt <jengelh@computergmbh.de>:
>
> On Jun 27 2007 14:05, Chris Shoemaker wrote:
> >
> >What I'd really like to see is, _why_ is trailing whitespace
> >considered harmful?
>
> Consumes bytes you'll never see :)
>
> >Something about MUAs not preserving it or something?
>
> 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
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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.
+

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Josh Triplett]

dave young wrote:
> 2007/6/27, Jan Engelhardt <jengelh@computergmbh.de>:
>> On Jun 27 2007 14:05, Chris Shoemaker wrote:
>>> What I'd really like to see is, _why_ is trailing whitespace
>>> considered harmful?
>> Consumes bytes you'll never see :)
>>
>>> Something about MUAs not preserving it or something?
>> 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
>> --
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> 
> 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.
> +
[...]

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[dave young]

>2007/6/28, Josh Triplett <josh@kernel.org>:
> dave young wrote:
> > 2007/6/27, Jan Engelhardt <jengelh@computergmbh.de>:
> >> On Jun 27 2007 14:05, Chris Shoemaker wrote:
> >>> What I'd really like to see is, _why_ is trailing whitespace
> >>> considered harmful?
> >> Consumes bytes you'll never see :)
> >>
> >>> Something about MUAs not preserving it or something?
> >> 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
> >> --
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >
> > 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.
> > +
> [...]
>
> 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.
>

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Jan Engelhardt]

On Jun 28 2007 06:29, dave young wrote:
>
> 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).

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
-- 

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Josh Triplett]

Jan Engelhardt wrote:
> On Jun 28 2007 06:29, dave young wrote:
>> 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).
> 
> 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.

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

RE: [PATCH] CodingStyle: Add information about trailing whitespace.

[Li Yang-r58472]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Josh Triplett
> Sent: Thursday, June 28, 2007 2:59 PM
> To: Jan Engelhardt
> Cc: dave young; Chris Shoemaker; Josh Triplett;
linux-kernel@vger.kernel.org;
> akpm@linux-foundation.org
> Subject: Re: [PATCH] CodingStyle: Add information about trailing
whitespace.
> 
> Jan Engelhardt wrote:
> > On Jun 28 2007 06:29, dave young wrote:
> >> 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).
> >
> > 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.
> 
> 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.

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

- Leo

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Dave Young]

>On 6/28/07, Li Yang-r58472 <LeoLi@freescale.com> wrote:
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Josh Triplett
> > Sent: Thursday, June 28, 2007 2:59 PM
> > To: Jan Engelhardt
> > Cc: dave young; Chris Shoemaker; Josh Triplett;
> linux-kernel@vger.kernel.org;
> > akpm@linux-foundation.org
> > Subject: Re: [PATCH] CodingStyle: Add information about trailing
> whitespace.
> >
> > Jan Engelhardt wrote:
> > > On Jun 28 2007 06:29, dave young wrote:
> > >> 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).
> > >
> > > 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.
> >
> > 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.
>
> No, vim works just fine here without leaving any indentation.  Maybe the
> version of vim or the options matter.
>
Yes, vim autoindent doesn't leave tabs in blank line for me.

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Dave Young]

>On 6/28/07, Dave Young <hidave.darkstar@gmail.com> wrote:
> >On 6/28/07, Li Yang-r58472 <LeoLi@freescale.com> wrote:
> > > -----Original Message-----
> > > From: linux-kernel-owner@vger.kernel.org
> > > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Josh Triplett
> > > Sent: Thursday, June 28, 2007 2:59 PM
> > > To: Jan Engelhardt
> > > Cc: dave young; Chris Shoemaker; Josh Triplett;
> > linux-kernel@vger.kernel.org;
> > > akpm@linux-foundation.org
> > > Subject: Re: [PATCH] CodingStyle: Add information about trailing
> > whitespace.
> > >
> > > Jan Engelhardt wrote:
> > > > On Jun 28 2007 06:29, dave young wrote:
> > > >> 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).
> > > >
> > > > 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.
> > >
> > > 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.
> >
> > No, vim works just fine here without leaving any indentation.  Maybe the
> > version of vim or the options matter.
> >
> Yes, vim autoindent doesn't leave tabs in blank line for me.
>
And for vim trailing space, there's a tip in vim.org:
http://www.vim.org/tips/tip.php?tip_id=878

[OT] Vim highlighting for trailing spaces

[Kyle Moffett]

On Jun 28, 2007, at 03:20:24, Dave Young wrote:
> And for vim trailing space, there's a tip in vim.org:
> http://www.vim.org/tips/tip.php?tip_id=878

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

Re: [OT] Vim highlighting for trailing spaces

[Jan Engelhardt]

On Jun 28 2007 23:11, Kyle Moffett wrote:
> 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

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
highlighted whitespace :-)

> The script mentioned there *is* good for removing said whitespace, though
>
> Cheers,
> Kyle Moffett
>

	Jan
-- 

Re: [OT] Vim highlighting for trailing spaces

[Josh Triplett]

Jan Engelhardt wrote:
> On Jun 28 2007 23:11, Kyle Moffett wrote:
>> 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
> 
> 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
> highlighted whitespace :-)

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

- Josh Triplett

Re: [OT] Vim highlighting for trailing spaces

[Jan Engelhardt]

On Jun 29 2007 00:53, Josh Triplett wrote:
>>> 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
>> 
>> 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
>> highlighted whitespace :-)
>
>And if you really want highlighting, you can always use grep --color. :)

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


	Jan
-- 

Re: [OT] Vim highlighting for trailing spaces

[Josh Triplett]

Jan Engelhardt wrote:
> On Jun 29 2007 00:53, Josh Triplett wrote:
>>>> 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
>>> 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
>>> highlighted whitespace :-)
>> And if you really want highlighting, you can always use grep --color. :)
> 
> Been there, done that, have GREP_COLOR env variable defined!

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

- Josh Triplett

Re: [OT] Vim highlighting for trailing spaces

[Björn Steinbrink]

On 2007.06.29 01:42:22 -0700, Josh Triplett wrote:
> Jan Engelhardt wrote:
> > On Jun 29 2007 00:53, Josh Triplett wrote:
> >> And if you really want highlighting, you can always use grep --color. :)
> > 
> > Been there, done that, have GREP_COLOR env variable defined!
> 
> Same here.  Now I just need to convince git-grep to use it.

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

Re: [OT] Vim highlighting for trailing spaces

[Dave Young]

On 6/29/07, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2007.06.29 01:42:22 -0700, Josh Triplett wrote:
> > Jan Engelhardt wrote:
> > > On Jun 29 2007 00:53, Josh Triplett wrote:
> > >> And if you really want highlighting, you can always use grep --color. :)
> > >
> > > Been there, done that, have GREP_COLOR env variable defined!
> >
> > Same here.  Now I just need to convince git-grep to use it.
>
> 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
>
I ussualy prefer the simple vim search command:
/\ *$

Re: [OT] Vim highlighting for trailing spaces

[Michael Tokarev]

Kyle Moffett wrote:
> On Jun 28, 2007, at 03:20:24, Dave Young wrote:
>> And for vim trailing space, there's a tip in vim.org:
>> http://www.vim.org/tips/tip.php?tip_id=878
> 
> 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.

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

Re: [OT] Vim highlighting for trailing spaces

[Dmitry Torokhov]

On 6/29/07, Michael Tokarev <mjt@tls.msk.ru> wrote:
> Kyle Moffett wrote:
> > On Jun 28, 2007, at 03:20:24, Dave Young wrote:
> >> And for vim trailing space, there's a tip in vim.org:
> >> http://www.vim.org/tips/tip.php?tip_id=878
> >
> > 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.
>
> 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.
>

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
middle of the line:

:highlight RedundantSpaces ctermbg=red guibg=red
:match RedundantSpaces /\s\+$\| \+\ze\t/

-- 
Dmitry

Re: [OT] Vim highlighting for trailing spaces

[Kyle Moffett]

On Jun 29, 2007, at 08:49:42, Dmitry Torokhov wrote:
> On 6/29/07, Michael Tokarev <mjt@tls.msk.ru> wrote:
>> 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.
>>
>
> 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 middle of the line:
>
> :highlight RedundantSpaces ctermbg=red guibg=red
> :match RedundantSpaces /\s\+$\| \+\ze\t/

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

Kyle Moffett wrote:
> It always displays trailing whitespace and spaces-before tabs...  
> except if your cursor is at the end of the whitespace.

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Andy Isaacson]

On Wed, Jun 27, 2007 at 11:58:30PM -0700, Josh Triplett wrote:
> Jan Engelhardt wrote:
> > On Jun 28 2007 06:29, dave young wrote:
> >> 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).
> > 
> > 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.
> 
> 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.

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

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Andrew Morton]

On Wed, 27 Jun 2007 10:59:20 -0700
Josh Triplett <josht@linux.vnet.ibm.com> wrote:

> +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.

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.

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Jan Engelhardt]

On Jun 27 2007 12:31, Andrew Morton wrote:
>
>quilt has ways of detecting and/or correcting newly-added trailing
>whitespace, but I don't know the details.

Upon `quilt ref`, it usually barfs about every line you touched where you
added or kept whitespace at EOL.

>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>
>But there's less than there used to be.

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


	Jan
-- 

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Oleg Verych]

> Newsgroups: gmane.linux.kernel
> Date: Wed, 27 Jun 2007 12:31:22 -0700

><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.

    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
editors, not sources!

> But there's less than there used to be.
____

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Anton Vorontsov]

On Fri, Jun 29, 2007 at 07:43:59PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 21:52 +0400, Anton Vorontsov wrote:
> > Andrew, regarding git-battery-vs-git-acpi.patch.. I'll merge it as
> > soon as acpi related changes will hit Linus tree, would that be okay
> > for you? Not that I don't like these changes, I do like them. But
> > they'll break bare battery2-2.6 (based on Linus tree). Though, I can
> > merge it now if that will make your living easier.
> 
> Was anyone working on hooking up APM and ACPI to the new battery class,
> btw?

Don't know of anyone yet. But lets inquire appropriate people, I don't have
x86 hardware with batteries, thus I hardly can help on that matter, nor
following any x86 development.

Henrique de Moraes Holschuh (IBM ACPI EXTRAS maintainer) was involved in
battery class review, Cc'ed. Also Cc'ing ACPI BATTERY maintainer, and
linux-acpi list.

Just reminder: we're talking about power supply class, its git tree
is at git://git.infradead.org/users/cbou/battery2-2.6.git, you may also
find it in recent -mm patchsets. Most interesting directory is
drivers/power/, contains power supply class and drivers, plus header
file at include/linux/power_supply.h. Also,
Documentation/power_supply_class.txt exits.

Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.org/bd2

Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Henrique de Moraes Holschuh]

On Fri, 29 Jun 2007, Anton Vorontsov wrote:
> On Fri, Jun 29, 2007 at 07:43:59PM +0100, David Woodhouse wrote:
> > On Fri, 2007-06-29 at 21:52 +0400, Anton Vorontsov wrote:
> > > Andrew, regarding git-battery-vs-git-acpi.patch.. I'll merge it as
> > > soon as acpi related changes will hit Linus tree, would that be okay
> > > for you? Not that I don't like these changes, I do like them. But
> > > they'll break bare battery2-2.6 (based on Linus tree). Though, I can
> > > merge it now if that will make your living easier.
> > 
> > Was anyone working on hooking up APM and ACPI to the new battery class,
> > btw?
> 
> Don't know of anyone yet. But lets inquire appropriate people, I don't have
> x86 hardware with batteries, thus I hardly can help on that matter, nor
> following any x86 development.
> 
> Henrique de Moraes Holschuh (IBM ACPI EXTRAS maintainer) was involved in
> battery class review, Cc'ed. Also Cc'ing ACPI BATTERY maintainer, and
> linux-acpi list.

The thinkpad full SBS interface is only accessible through code that is not
in-tree.  I am sending this reply to Shem Multinymous, which maintains that
code (tp_smapi).

> Just reminder: we're talking about power supply class, its git tree
> is at git://git.infradead.org/users/cbou/battery2-2.6.git, you may also
> find it in recent -mm patchsets. Most interesting directory is
> drivers/power/, contains power supply class and drivers, plus header
> file at include/linux/power_supply.h. Also,
> Documentation/power_supply_class.txt exits.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh