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

On Sun, Dec 16, 2007 at 12:40:59PM -0800, Junio C Hamano wrote:

"J. Bruce Fields" [off-list ref] writes:

quoted

One slightly weird thing about this: I'd expect indent-with-non-tab to
catch any sequence of 8 or more contiguous spaces, not just such
sequences at the end of the indent.  This doesn't quite do that.

+-------+-------+-------+-------+-------+-------+-------+-------+-------+
Personally, I would hate that.  That would muck with two spaces I
deliberately typed after the full stop before this sentence).  Please
don't.

Right, I was only thinking of literal sequences of 8 contiguous spaces,
and only in the initial indent.  So it's the failure to flag

	"^\t         \t"

that I find a little unexpected.  Whatever--I don't think it's
particularly important.  Like I say, I think there's really only two
cases anyone really cares about:

	1. The kernel or git style, where all initial whitespace is
	tabbed as much as possible.
	2. Various other styles which may be harder to check completely,
	but which are likely to share the "no spaces before tabs in
	initial indent" rule as a least common denominator.

Emacs "M-x tabify" tends to do this and I found it unsuitable especially
for code (I am not complaining, it probably was invented for other
purposes and not reformatting code):

If you have original (the run of '>>..>>' is a single tab, '.' is a SP)

        dcba....123
        fedcba..123
        gfedcba.123

and "tabify" the region, you would get:

        dcba>>>>123
        fedcba>>123
        gfedcba.123

That is fine if you are shooting for minimum number of bytes, but often
it is not what you want in your code, especially when the part that
conains the whitespace "..cba 123.." is inside a string constant.

Yeah, that sounds pretty irritating.

--b.