-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using named subpatterns #121
Comments
Yes, I totally agree. In fact I'm working on a significantly improved link parser ( |
Why is there "after" sub-pattern in Parser::doSpecial()? Its optional (? repetition), so it doesn't really do anything. The after symbol is neither shelved so it must not be about interfering with parsing either. fbb5e91 |
I suppose it has been used in the past, or for just consistency purposes. I've decided to drop it since it doesn't do anything at this point, and can actually be missing leading to additional code. If the sub-pattern is ever needed back it probably should be changed to a dot, if there must be no restriction on the tag ending. |
This would make parts of the code more readable (the patterns itself) and remove those order dependent list() statements.
The numeric subpattern and list() export is somewhat error prone; the are in two different places. If the order ever happens to change, the list statement will also need updating. But if you accidentally miss one of them, that list statement breaks on the offset change position, which might go unnoticed if a test doesn't use that attribute on some very specific tag.
The text was updated successfully, but these errors were encountered: