Josh Triplett <josh@xxxxxxxxxxxxxxx> writes:
> My standard test case for this:
>
> fprintf("some very long string",
> arguments);
>
> Type the first line, and press enter. A good editor should indent to
> the open parenthesis. However, it should not use a tab, because it
> needs to match up with the length of "fprintf(".
Sorry, I do not want to go into ideology or be anal, but I have
to disagree. Tab width is 8 spaces (in the kernel and git), so
"fprintf(" from the beginning of the line and an HT at the
beginning of the line have the same width.
Your project may have different conventions. Then you do not
have to use that option to check for 8 or more leading spaces.
And honestly, I think responding to that by saying "but somebody
can have tab width that is not 8" is irrelevant. Somebody else
can even use a non-proportional font to print it, so your 8
spaces and "fprintf(" won't line up ANYWAY.
If you REALLY want to be anal, then the rules to follow would
be:
- Do not assume you know the width of a HT, other than that the
same number of HT at the beginning of two lines indent to the
same distance from the left margin, and more of them indent
deeper;
- Do not assume the text will be printed in monospace;
which leads to:
- Indent with the same number of HT from the beginning of
lines. Go deeper with one more HT, go shallower with one
less HT.
- Start the continuation line with the same number of HT to
indent but DO NOT BOTHER aligning. There is no alignment,
period.
I happen to choose to be less anal, and accept 8 space HT _and_
monospace font. So "complaining at >=8 SP at the beginning"
makes perfect sense, so does a corresponding patch to convert
such runs of SPs to HTs with "git-apply --whitespace=fix" (which
should require an option to be enabled, and the is not here
yet) when applying a patch.
-
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
