Re: [PATCH] whitespace: fix initial-indent checking

["J. Bruce Fields" <bfields@fieldses.org>]

On Sun, Dec 16, 2007 at 07:16:44PM +0100, Jakub Narebski wrote:
> J. Bruce Fields wrote:
> > No, the previous version didn't work for the align-with-spaces case
> > either.  Consider, for example,
> > 
> > struct widget *find_widget_by_color(struct color *color,
> >                                     int nth_match, unsigned long flags)
> > 
> > If following a "indent-with-tabs, align-with-spaces" policy, then the
> > initial whitespaace on the second line should be purely spaces
> > (otherwise adjusting the tab stops would ruin the alignment).  But
> > indent-with-non-tab would flag this as incorrect even before my fix.
> 
> Yes, this is (if we want "indent with tab, align with spaces") false
> positive even with current version of indent-with-non-tab policy, but
> it is _rare_ false positive.

You can find examples like the above all over the git source, even in C
where the top-level code is indented in main().

> It is useful because it catches quite common "indent with spaces only",
> for example if MTA or editor replaces tabs with spaces, or if editor
> preserves whitespace but it uses spaces for indent.
> 
> So for me this version is a good compromise between false positives
> and catching real indent whitespace errors. The version proposed has
> IMHO too many false positive, while I guess not catching much more
> errors in practice.

Unfortunately, this compromise wouldn't solve my problem.

Which is: I do get the occasional kernel patch with whitespace problems
uncaught by git's existing checks.  It's annoying to have to fix them up
manually (but wastes Andrew Morton's time if I don't).  This shouldn't
be necessary, because the kernel has a simple policy for initial
whitespace that is completely automatable.

If we've got to define a fourth whitespace policy for this, well, OK,
I'll live--tell me what I need to do.  I haven't seen a convincing
argument for that yet, though.

--b.