Signed-off-by: Josh Triplett <[email protected]>
---
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
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
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
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
On Wed, 27 Jun 2007 10:59:20 -0700
Josh Triplett <[email protected]> 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.
> 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.
____
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
--
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
--
2007/6/27, Jan Engelhardt <[email protected]>:
>
> 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 [email protected]
> 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.
+
dave young wrote:
> 2007/6/27, Jan Engelhardt <[email protected]>:
>> 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 [email protected]
>> 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
>2007/6/28, Josh Triplett <[email protected]>:
> dave young wrote:
> > 2007/6/27, Jan Engelhardt <[email protected]>:
> >> 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 [email protected]
> >> 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
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
--
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
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Josh Triplett
> Sent: Thursday, June 28, 2007 2:59 PM
> To: Jan Engelhardt
> Cc: dave young; Chris Shoemaker; Josh Triplett;
[email protected];
> [email protected]
> 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
>On 6/28/07, Li Yang-r58472 <[email protected]> wrote:
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Josh Triplett
> > Sent: Thursday, June 28, 2007 2:59 PM
> > To: Jan Engelhardt
> > Cc: dave young; Chris Shoemaker; Josh Triplett;
> [email protected];
> > [email protected]
> > 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.
>On 6/28/07, Dave Young <[email protected]> wrote:
> >On 6/28/07, Li Yang-r58472 <[email protected]> wrote:
> > > -----Original Message-----
> > > From: [email protected]
> > > [mailto:[email protected]] On Behalf Of Josh Triplett
> > > Sent: Thursday, June 28, 2007 2:59 PM
> > > To: Jan Engelhardt
> > > Cc: dave young; Chris Shoemaker; Josh Triplett;
> > [email protected];
> > > [email protected]
> > > 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
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
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
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
--
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
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
--
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
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
On 6/29/07, Bj?rn Steinbrink <[email protected]> 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:
/\ *$
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
On 6/29/07, Michael Tokarev <[email protected]> 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
On Jun 29, 2007, at 08:49:42, Dmitry Torokhov wrote:
> On 6/29/07, Michael Tokarev <[email protected]> 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