You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
I am using the TagFinder class provided by this package in my own Atom package and have an issue with its behavior. Its method findEndTag() matches tag names by substring and will therefore result in false positives, messing up any attempt at proper tag matching.
Consider this snippet:
<foo-t><foo-too></foo-too></foo-t>
If I execute TagFinder.findEndTag('foo-t', { row: 0, column: 7 }), the method will return 'foo-too', matching the wrong end tag on line 2, instead of the actual end tag on line 3.
Looking at how the regular expression for matching tags is written, this could even be intended behavior, as the regex is clearly written to allow any end tag that simply starts with the passed name. Therefore I don't provide any suggestions for patching this. At least it could be checked after the regex matching that captured tag name is an exact match and not a simple substring match.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am using the TagFinder class provided by this package in my own Atom package and have an issue with its behavior. Its method findEndTag() matches tag names by substring and will therefore result in false positives, messing up any attempt at proper tag matching.
Consider this snippet:
If I execute
TagFinder.findEndTag('foo-t', { row: 0, column: 7 })
, the method will return 'foo-too', matching the wrong end tag on line 2, instead of the actual end tag on line 3.Looking at how the regular expression for matching tags is written, this could even be intended behavior, as the regex is clearly written to allow any end tag that simply starts with the passed name. Therefore I don't provide any suggestions for patching this. At least it could be checked after the regex matching that captured tag name is an exact match and not a simple substring match.
The text was updated successfully, but these errors were encountered: