[[FIX]] Improve handling of tab indentation.

[TzviPM]

By tracking the column number both with and without soft tabs,
we enable better messages for errors and warnings. This is especially
useful for editor linting integrations.

Fixes #3151

[coveralls]

Coverage increased (+0.004%) to 98.757% when pulling 07513d5 on tzvipm:master into e0b4e91 on jshint:master.

[jugglinmike]

Thanks for the patch! This problem has been causing a lot of headaches, as gh-3151 demonstrates. I'm definitely interested in moving forward with this, but I think we need to reformat it a bit first.

The current behavior is somewhat surprising, but it is also poorly-documented. At the moment, the documentation of the data reported by JSHint is limited to a single example on jshint.com, and that example does not even include the corresponding input text. Over the years, consumers have been forced to discover the feature and learn its behavior experimentally. So as surprising as we may find the behavior, it's possible that code out there has come to rely on it. Of course, anyone could be relying on any flaw in JSHint's implementation, and this alone isn't enough to stop us from fixing bugs. The extenuating circumstance here is the poor state of the documentation and the ambiguity of the expected behavior.

That's why I think we need to introduce this as a new feature rather than a bug fix. What do you think of this:

• We expose the new value via a new property on the report object named column
• We continue to expose the character attribute without change
• We document the entire report object, defining exactly what each property is intended to describe and labeling the character attribute as "deprecated"
• We merge this patch to the v2.10.0 feature branch for inclusion in the next minor release of JSHint

Like the first draft you've submitted here, this approach fixes the problem for the folks that need it. On top of that, it avoids disrupting existing code, and it also gives us a clear path to the next major release, where the confusing character property can be removed entirely. (I kind of like the name "column" better anyway because "character" could describe a few things--a code point, its offset within the line, or even its offset within the entire input stream.)

So what do you think? Would you be up for that work? Depending on how you want to proceed, it may involve rebasing your branch. As noted in that "work-in-progress" pull request for version 2.10.0, I'd be happy to help you with that.

[Arcanemagus]

I'd certainly be happy with moving to a different property in the result if it means being able to close the ~40 issues I've got open tracking this 😆.

[cobexer]

Just fell over this issue again...