132 Add test match with spaces in braces

[JohJohan]

Fixes 132

[JohJohan]

I wasn't able to run it localy as i'm using windows and cmake doesn't want to build the tests

[greut]

you've added a fixture, the tests are there: https://github.com/editorconfig/editorconfig-core-test/blob/master/glob/CMakeLists.txt#L120=

[JohJohan]

@greut i added a test for braces with spaces. But still i wasn't able to run the test i get:

Command: "/usr/bin/cmake" "-D" "EDITORCONFIG_CMD=the_editorconfig_core_cmd_you_want_to_test" "-D" "ECARGS:LIST=-f;meta.in;/mnt/d/mega/www/projecten/editorconfig-core-test/meta/meta.c" "-P" "/mnt/d/mega/www/projecten/editorconfig-core-test/cmake/ec_sort.cmake"
Directory: /mnt/d/mega/www/projecten/editorconfig-core-test/meta
"meta_multiline" start time: May 27 11:44 CEST
Output:
----------------------------------------------------------
CMake Error at /mnt/d/mega/www/projecten/editorconfig-core-test/cmake/ec_sort.cmake:61 (message):
  the_editorconfig_core_cmd_you_want_to_test
  -f;meta.in;/mnt/d/mega/www/projecten/editorconfig-core-test/meta/meta.c
  returned a nonzero exit code


<end of output>
Test time =   0.09 sec
----------------------------------------------------------
Test Fail Reason:
Required regular expression not found.Regex=[^[
]*answer=42[ 	

]+$
]
"meta_multiline" end time: May 27 11:44 CEST
"meta_multiline" time elapsed: 00:00:00
----------------------------------------------------------

[cxw42]

Remove line 132, which duplicates line 126.

[JohJohan]

Removed, how can i test that a extension is not matched based on choice=spaces might be nice to add a test like that what do you think?

[cxw42]

Ah! Sorry for misunderstanding. Yes, we can test for non-matching. However, the test filename has to be one that is not matched anywhere in the .in file. How about?---

-new_ec_test(braces_word_choice8 braces.in test.pyc "^[ \t\n\r]*$")
+new_ec_test(braces_word_choice8 braces.in test.NOMATCH "^[ \t\n\r]*$")

Edit why "has to be one that is not matched" --- the new_ec_test() function runs the core with the given inputs filename and returns all matching key/value pairs. So, if the .in file has multiple sections, you can't test for whether only one section matches.

[JohJohan]

Ah oke make sense, I thought it might be good idea to test a case that didn't match a specific selector as I had a case that didn't work for me see: editorconfig-checker/editorconfig-checker#198

If you think current test are enough I can agree :)

[JohJohan]

@greut / @cxw42 have time to take a look again?

[cxw42]

✅ as of 2e91280

[xuhdev]

Are we sure this is desirable though? The specification doesn't discuss the case in which spaces are present: https://editorconfig-specification.readthedocs.io/#glob-expressions

[JohJohan]

@xuhdev I think the more strict it is the better. So I would say no spaces allowed. But as mentioned here editorconfig-checker/editorconfig-checker#198 (comment) the docs says spaces are allowed.

So if we say no spaces I would write a test that a spaces match doesn't match anything. And we should update the docs.

[xuhdev]

My interpretation of the spec (and based on super early discussion on the glob format) is that space should not be allowed, because we want to avoid unnecessary workload from implementing glob parsers. Actually, I believe the fact that the absence of a particular pattern should generally imply that it's unavailable rather than that variants are allowed.

[JohJohan]

Its been a while and i stumbled on this pull request again. @xuhdev as i understand correctly we dont want to have the space that make sense. Than we can close this merge right as this just proves it is allowed. Also no doc changes are needed right?

[xuhdev]

Its been a while and i stumbled on this pull request again. @xuhdev as i understand correctly we dont want to have the space that make sense. Than we can close this merge right as this just proves it is allowed. Also no doc changes are needed right?

Yes, that's my interpretation of the spec.