Clarify the indent_size spec option

[mipo256]

We need to clarify the indent_size specification option. Maybe we can think about adding new non-normative section as well.

Assume we have these .editorconfig settings:

indent_style = space
indent_size = 2

And we also have the following Java code:

1. package com.something.other;
2. 
3. import java.util.function.Consumer;
4. 
5. public class TestJavaClass {
6. 
7.   public static final String PARAM = "PARAM";
8.
9.  private static final Consumer<Object> MY_CONS = o ->
10.    System.out.println(o);
11.
12.  public static void main(String[] args) {
13.    System.out.println("Hey!");
14.
15.    String property = System
16.      .getProperties()
17.      .getProperty(PARAM);
18.
19.   if (property == null)
20.      return;
21.
22.    System.out.println(property);
23.  }
24.}

The problem is that the spec does not specify the exact indentation rules. For instance, I can implicitly infer the rule, that the intention size of the line must be either the same as the previous (which is, let's say, equal to X), or it should be of the value X + indent_size. That is fine, but there are a couple of problems:

1. What is the indent size of the line 19 should be? The problem is that we do not have a previous line to look up the indentation according to the rule I described above. We can of course track the indentation of the latest non-empty new line, and then apply the rule above, but this is not mentioned in the spec. It should be somehow clarified.

2. What is the indentation size of the line 23 should be? On the one hand, this bracket closes the main() method, but it can equally close some if/else statement. The spec does not specify this behavior. But it should

[cxw42]

Is this covered by editorconfig/editorconfig#521?

[mipo256]

No, unfortunately it does not. This issue is far more deep then the one you mention @cxw42

[cxw42]

The spec does not specify this behavior. But it should

Hmm... I'm not convinced this is the case. I agree that adding detail to the specification reduces the risk of two editors producing different outputs. However, I am not sure that seeking that level of detail is the best use of our time at present.

Example

Consider GNU vs. Google/Mozilla conditionals in C:

// GNU, `indent -bl -i2`
if (cond)
  {
    other_stmt;
  }

// Google/Mozilla, `indent -br -i2`
if (cond) {
  other_stmt;
}

Both have indent_size = 2, but the indentation of other_stmt; depends on parameters besides indent_size. How would we specify this in the spec for indent_size?

General comment

I am not sure EditorConfig can meaningfully specify the behaviour of editors ("editors" including autoformatters or other tools). It can and does specify the inputs to those tools:

“Editors” ... use plugins to update settings for files being edited.

(from the spec, emphasis added).

Suppose we did try to fully specify behaviour. We would need to at least cover all of the clang-format options, and that's a pretty long list!

[mipo256]

Both have indent_size = 2, but the indentation of other_stmt; depends on parameters besides indent_size. How would we specify this in the spec for indent_size?

@cxw42 You got my concern. Maybe we should not standardize it, but maybe add a non-normative section in spec or a wiki page that explains clearly, that sometimes for a rule interpretation might be multiple right answers. Because now, when I read the spec, I do have a lot of questions like how is it technically possible to implement it? Like, how exactly the editor would reformat my code if I have indent_size = 2? What exactly I can expect from implementation?

The answer is - there is no single right answer. And it is not clear from the spec at all. There are multiple ways to do indent_size.

Some rules in the spec are definitive, like trim_trailing_whitespace. There is a formal definition of a whitespace, and we know what "trailing" means. There is only one right answer here:

int a = 23;<IMMEDIATE EOL>

It is not questionable. But with indent_size = X there are multiple right answers.

I hope the concern is clear now. Some rules have multiple right answers, and some do not. However, we do not make such a distinction in the spec and that is confusing.