On Sun, Dec 16, 2007 at 11:00:55AM +0100, Wincent Colaiuta wrote:
> El 16/12/2007, a las 10:08, Jakub Narebski escribió:
>
>> J. Bruce Fields wrote:
>>
>>> This allows catching initial indents like '\t ' (a tab followed
>>> by 8 spaces), while previously indent-with-non-tab caught only indents
>>> that consisted entirely of spaces.
>>
>> I prefer to use tabs for indent, but _spaces_ for align. While previous,
>> less strict version of check catches indent using spaces, this one also
>> catches _align_ using spaces.
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.
> I'd say that Jakub's is a fairly common use case (it's used in many places
> in the Git codebase too, I think) so it would be a bad thing to change the
> behaviour of "indent-with-non-tab".
>
> If you also want to check for "align-with-non-tab" then it really should be
> a separate, optional class of whitespace error.
I would agree with you if it were not for the fact that if you're using
an "indent-with-tabs, align-with-spaces" policy then the only indent
whitespace problems that you can flag automatically are space-before-tab
problems; anything else requires knowledge of the language syntax.
So indent-with-non-tab has only ever been useful for projects that
insist on tabs for all sequences of 8 spaces in the initial whitespace.
--b.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
