Ability to check indentation width for soft tabs about eclint

[jednano]

@mcandre the issue is not specific to eclint. It's just a problem with logic. Say you have a JavaScript file with soft tabs for indentation. This means you are using spaces for indentation, but also spaces for alignment. So how do I know which spaces are indentation vs. which ones are intended for alignment? I don't! For example:

function foo(bar,
             baz,
             qux) {
    return bar + baz + qux;
}

Notice how I am using 4 spaces for indentation here, which you can see on line 4. There are 4 spaces that precede the return statement. I also have 13 spaces to align baz and qux with the opening paren of the foo function. Is that 3 indents followed by 1 space for alignment? Or is it 1 indent followed by 9 spaces of alignment? Neither! But how do I know? I don't! There's no way that I know to logically distinguish between spaces intended for indentation vs. alignment. I can't make any assumptions here.

Now, let's consider the same scenario with tabs for indentation and spaces for alignment.

function foo(bar,
             baz,
             qux) {
    return bar + baz + qux;
}

Line 4 is the only one with a leading tab; therefore, the only line with actual indentation. Lines 2 and 3 are still using 13 spaces and I can safely assume they were intended for alignment and not indentation. In fact, if this whole block were indented once with one tab, I could easily still decipher between what was intended for indentation (leading tabs) and what was intended for alignment (any spaces that follow).

Notice, this is totally different than mixed tabs with spaces. I'm not condoning the use of tabs, followed by spaces, followed by more tabs. That is totally uncalled for! I'm simply stating that tabs for indentation and spaces for alignment is the only true way to make safe assumptions about the code's indentation.

[mcandre]

Thanks for the detailed response! That's a good point.

I don't align function arguments this way, I use K&R C-family style myself, so it never occurred to me that this might be a problem.

Hmm, if there were a configurable like align_arguments or such, we could at least turn on soft tab indentation checking when align_arguments was false.

[jednano]

It's not limited to function parameter alignment. The same issue presents itself with var statement alignment. I'm sure there are a ton more examples.

var firstName = 'Jed',
    lastName  = 'Mao';

Aligning arguments is rather language specific, so your suggestion doesn't make a lot of sense for EditorConfig, which is language agnostic. Instead, it would be the responsibility of language-specific tools. In the case of JavaScript, Esprima.

Really, to do any amount of source rewrite, you'd need some kind of concrete syntax tree for each type of language. Unfortunately, this is probably not available for most languages, if any. It's definitely not available for JavaScript as of yet.

BTW, all of this nonsense just ads fuel to an already burning flame I have against spaces for indentation. I'm a huge proponent of tabs for indentation, followed by spaces for alignment. I just think there are too many misconceptions about it that people don't know how it's done properly. I should probably put together a video demonstration on the matter at some point.

@mcandre can I close this issue or is there more to discuss on the matter?

[mcandre]

Yes, feel free to close this for now, it's an inherently thorny issue. Note that hard tabs make it even more difficult to line up argument list items / declaration names.

I'm agnostic on spaces vs tabs. They both present problems.

[jednano]

@mcandre, if your point is that it's more difficult to hit tab and then switch to hitting the spacebar n number of times for alignment, I see your point. It would be more convenient to just hit the tab key to get you 20 spaces deep, right? Yes, that is a valid argument. Thank you for pointing that out. I just don't think it holds enough weight concerning the programmability of reverse engineering one's intent, which is a huge loss of information with spaces for indentation. Your argument is, in fact, the only valid argument against hard tabs I've ever heard. I just don't think it trumps the cons of soft tabs. Your feedback is valued though, so feel free to continue this conversation if you have more input.

[mcandre]

What if we used astyle to help? I think astyle can do this for a variety of programming languages, we'd just need to hook it up to editorconfig's indentation configuration.

[jednano]

I think @treyhunner would agree that this is outside the scope of EditorConfig. If you want to use astyle go right ahead, but I don't think EditorConfig will ever have language-specific concerns.

[treyhunner]

I haven't followed the discussion well, but I do want to reiterate that EditorConfig is meant to be a standard for automatically enforcing a basic universal style guide as well as an file format that can be extended for more opinionated and less universal standardization. Others have already created tooling that uses .editorconfig files for related purposes.

[xuhdev]

@mcandre I have a project which currently takes advantages of existing styling tools to fix source code problems with EditorConfig. Currently I only implemented C code handling with uncrustify. Maybe you are interested to contribute to this project? I don't have much time on it.

[jednano]

For the record, Esprima will be the JavaScript-specific tool to perform code rewrites, but it has the potential to throw away some information in the process, like comments within function parameters. I'm pretty sad about this.

[mcandre]

@xuhdev Excellent!

One day it would be nice to hook editorconfig up to these, eventually supporting indentation warnings for many languages at once.

[xuhdev]

@mcandre
Would you like to help out, I wonder, as my time is very limited.