-
Notifications
You must be signed in to change notification settings - Fork 63
Fix for atom/language-xml#91 and atom/language-xml#96 #101
base: master
Are you sure you want to change the base?
Conversation
atom#96 already provides all the details about the issues fixed here. atom#87 (comment) has the correct code but merge included some extra indent which causes the rule not to work properly. In relation with atom#91, a `begin` without `end` or `while` was added but this is not valid as `begin` should always have a corresponding `end` or `while`. `match` should be used instead of `begin`
Regardless of whether the changes here stay the same, I think it would be good overall if we had a couple of extra tests to better explain what kind of output we expect from snippets containing We can wait till the proposal in the corresponding issue gets finalized and then look at which tests exactly have to be implemented so that the tests do not need to be redone multiple times. |
@vfcp could you add some tests? |
I've added a test for Below is the test and the list of tokens generated for your review: it 'tokenizes after invalid comment only if comment was properly closed', ->
{tokens} = grammar.tokenizeLine('<!-- invalid -- comment ---><n></n>--><n></n>')
expect(tokens[0]).toEqual value: '<!--', scopes: ['text.xml', 'comment.block.xml', 'punctuation.definition.comment.xml']
expect(tokens[1]).toEqual value: ' invalid ', scopes: ['text.xml', 'comment.block.xml']
expect(tokens[2]).toEqual value: '--', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[3]).toEqual value: ' comment -', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[4]).toEqual value: '--', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[5]).toEqual value: '><n></n>', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[6]).toEqual value: '-->', scopes: ['text.xml', 'comment.block.xml', 'punctuation.definition.comment.xml']
expect(tokens[7]).toEqual value: '<', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[8]).toEqual value: 'n', scopes: ['text.xml', 'meta.tag.no-content.xml', 'entity.name.tag.xml', 'entity.name.tag.localname.xml']
expect(tokens[9]).toEqual value: '>', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[10]).toEqual value: '</', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[11]).toEqual value: 'n', scopes: ['text.xml', 'meta.tag.no-content.xml', 'entity.name.tag.xml', 'entity.name.tag.localname.xml']
expect(tokens[12]).toEqual value: '>', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml'] |
The tests seem sufficient for now, however I (and probably also you) noticed that becuase of the |
While testing your suggestion to use To summarize, this is the current rule. It's basically the same rule as before PR with addiction of {
'begin': '<!--'
'captures':
'0':
'name': 'punctuation.definition.comment.xml'
'end': '-->'
'name': 'comment.block.xml'
'patterns': [
{
'begin': '--(?!>)'
'end': '(?<!-)(?=-->)'
'name': 'invalid.illegal.bad-comments-or-CDATA.xml'
}
]
}
List of tokens produced: it 'tokenizes after invalid comment only if comment was properly closed', ->
{tokens} = grammar.tokenizeLine('<!-- invalid -- comment ---><n></n>--><n></n>')
expect(tokens[0]).toEqual value: '<!--', scopes: ['text.xml', 'comment.block.xml', 'punctuation.definition.comment.xml']
expect(tokens[1]).toEqual value: ' invalid ', scopes: ['text.xml', 'comment.block.xml']
expect(tokens[2]).toEqual value: '--', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[3]).toEqual value: ' comment ---><n></n>', scopes: ['text.xml', 'comment.block.xml', 'invalid.illegal.bad-comments-or-CDATA.xml']
expect(tokens[4]).toEqual value: '-->', scopes: ['text.xml', 'comment.block.xml', 'punctuation.definition.comment.xml']
expect(tokens[5]).toEqual value: '<', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[6]).toEqual value: 'n', scopes: ['text.xml', 'meta.tag.no-content.xml', 'entity.name.tag.xml', 'entity.name.tag.localname.xml']
expect(tokens[7]).toEqual value: '>', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[8]).toEqual value: '</', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml']
expect(tokens[9]).toEqual value: 'n', scopes: ['text.xml', 'meta.tag.no-content.xml', 'entity.name.tag.xml', 'entity.name.tag.localname.xml']
expect(tokens[10]).toEqual value: '>', scopes: ['text.xml', 'meta.tag.no-content.xml', 'punctuation.definition.tag.xml'] I've also added an additional test for the |
Thank you for pointing this out, I'm glad at least we got one extra test out of it. I know for certain that we can do better, but at this point I'm not sure how easy it would be. We have made it clear enough that it's unintentional that multiple tokens are generated, but also realize that nobody should be impacted at least right now (file an issue report or a pull request if you are). The test suite should support now enough cases to not break it in a dumb manner in the future. |
@vfcp actually I think this is simpler than I thought before, we could move |
@Ingramz Updated rule and tests as suggested. I've tested in Linguist and VSCode as well to make sure behavior is same as expected. |
Excellent! @darangi it should be now good to review/merge. |
#96 already provides all the details about the issues fixed here.
#87 (comment) has the correct code but merge included some extra indent which causes the rule not to work properly.
In relation with #91, a
begin
withoutend
orwhile
was added but this is not valid asbegin
should always have a correspondingend
orwhile
.match
should be used instead ofbegin
Requirements
Description of the Change
The details are already discussed in detail in both issues #91 and #96.
Alternate Designs
N/A
Benefits
Fix invalid rules for JSP style comments, fixes #91
Possible Drawbacks
None
Applicable Issues
#91 #96