Add support for newlines in selectors

[subtleGradient]

https://github.com/subtleGradient/SubtleGradient-Themes.tmbundle/blob/master/Themes/Brilliance%20White.tmTheme#L671-L674

○ → node --harmony_collections $HOME/Downloads/Atom.app/Contents/Resources/app/apm/node_modules/atom-package-manager/lib/cli.js  init --theme "$HOME/.atom/packages/SubtleGradient-Themes-tmbundle-Themes-Brilliance-White-tmTheme" --convert "$PWD/SubtleGradient Themes.tmbundle/Themes/Brilliance White.tmTheme"
Expected "(", "-", [ \t], [*], [LRB], [a-zA-Z0-9+_] or end of input but "\n" found.

[Ingramz]

Out of interest I took a look at this. The error is actually somewhat correct or should point out that you have a mistake there.

The scope selector component in TextMate processes this "scope" you highlighted exactly as if it were meta.group.braces.round punctuation.section.scope, . This is the first line of the string without end of line character. The parsing component found an unknown character - in this case \n and stopped parsing the scope. Because semantically the parsing ended at comma, only the alternatives preceding that comma are considered in TextMate, in this case just the first one.

So all this time, the way TextMate has processed that specific scope has been meta.group.braces.round punctuation.section.scope, without considering any of the other alternatives. TextMate has never actually supported newlines in this case. Getting rid of newlines from scopes in plist should fix that for you.

Should Atom or first-mate silently fail in such cases? I do not think so, as it causes confusion. Probably finding a way to point user to documentation, which explains how to properly form scope selectors, would be the best way to tackle parse errors.

[winstliu]

Closing as wontfix. I agree with @Ingramz here.

And on that note, we seriously need to finish the grammar documentation.