Ignore leading whitespace in EditorConfig files about editorconfig HOT 17 CLOSED

Maybe we should add a test case first?

from editorconfig.

I agree. I've added two tests but I need to add more because cases such as this do not work:

[test]
test1=test1
    test2=test2
test3=test3

from editorconfig.

It doesn't matter if the test case does not work. We could add it first and then settle it down.

from editorconfig.

I tried this ini file with both python and inih:

[Protocol] ; Protocol configuration
Version=6 ; IPv6

    [User]
Name = Bob Smith ; Spaces around '=' are stripped
Email = [email protected] ; And comments (like this) ignored
Active = True ; Test a boolean

Test spaces_before_section_name should both fail for python version and C version.

from editorconfig.

And also, the following file works for neither C nor python version:

[Protocol] ; Protocol configuration
Version=6 ; IPv6

[User]
Name = Bob Smith ; Spaces around '=' are stripped
    Email = [email protected] ; And comments (like this) ignored
Active = True ; Test a boolean

The following one does not work with python:

[Protocol] ; Protocol configuration
Version=6 ; IPv6

[User]
    Name = Bob Smith ; Spaces around '=' are stripped
Email = [email protected] ; And comments (like this) ignored
Active = True ; Test a boolean

from editorconfig.

I just added another test (editorconfig/editorconfig-core-test@531c2ce).

Currently there is:

• spaces_before_property_name: tests that whitespace preceding a single property is ignored
• spaces_before_section_name: test that whitespace preceding section a name is ignored
• spaces_before_middle_property: test that whitespace preceding property that is in between other properties is ignored

Do all of these test cases look like correct behavior?

I know the Python and C code both fail some of these tests. We could either modify the code or modify the tests to match the behavior of the code (we will have to change some code regardless since they don't match each other perfectly).

from editorconfig.

seems like leading spaces are regarded as line continuation. May be we could keep this?

from editorconfig.

Ok. I will change the test case to test for continuations and make sure the Python code works with them.

from editorconfig.

It looks like the C code handles line continuations in an ambiguous manner (see this ticket I created for inih). What do you think we should do to resolve that issue?

from editorconfig.

I have come to the conclusion that we may want to remove support for continuations (treat them as invalid) for now and possibly add support later if the need arises. I have looked at the implementations of multiple INI parsers and I have not seen any that support line continuations except for Python's ConfigParser and inih (which supports them very differently).

What do you think about removing continuation support and requiring that sections and key/value pairs have no leading spaces? This way we would be able to add either continuations or support for leading spaces in the future.

from editorconfig.

I believe many parsers should implement line continuation.

http://en.wikipedia.org/wiki/INI_file#Varying_features

We could wait inih to fix this, or if it takes too much time, let's fix it by ourselves.

from editorconfig.

That link doesn't seem to mention line continuations using whitespace at all. It mentions that leading and trailing whitespace is often ignored (which would not be possible with continuations as implemented in ConfigParser):

Interpretation of whitespace varies. Most implementations ignore leading and trailing whitespace around the outside of the property name.

The reason I would be hesitant to implement line continuations is that it would disallow use of whitespace for indentation in any way (because it would be interpreted as a continuation). I'm not sure whether we would want to allow indentation, but I can't imagine what we would use continuations for either.

from editorconfig.

It mentions line continuation using escape:

Some implementations also offer varying support for an escape character, typically with the backslash (). Some support "line continuation", where a backslash followed immediately by EOL (end-of-line) causes the line break to be ignored, and the "logical line" to be continued on the next actual line from the INI file.

We are not sure whether we need line continuation in the future. But as you said, this will disallow use of white space for indentation, it seems that using white space as line continuation is not appropriate. OK, let's remove this feature.

from editorconfig.

The C version is fixed, all tests pass now: d6dc221a795b4cb4faaccfc47badacfbda76a625

from editorconfig.

So we have decided not to use continuations (at least for now).

I see 2 options now:

1. Ignore all leading whitespace

This will allow indentation to be used freely. However, if line continuations are added in the future may result in backwards incompatibility.

1. Consider leading whitespace as a parsing error

This will allow us to add line continuations or indentation in the future without breaking existing EditorConfig files. However, EditorConfig files that use these new features will not work with older EditorConfig parsers.

I don't think we are going to add line continuations in the future so I think option 1 may be acceptable.

from editorconfig.

We could also allow indentation and regards \ in the end of line to indicate line continuation in the future, and I think it's more common. What do you think?

from editorconfig.

That may be a different type of line continuation (often \ at end of line will not preserve the line break) but we could support that one in the future if needed.

I'll change the Python code to pass the current test cases and ignore leading whitespace.

from editorconfig.