-
Notifications
You must be signed in to change notification settings - Fork 40
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
Popping a looking ahead pattern immediately not working #1906
Comments
Not quite sure what is happening here, but looks similar to a bug that was fixed: #1190 |
It's 5:00am my time. Have to sleep now. Will try to fix it tomorrow. |
I suspect some infinite loop prevention kicking in. |
I don't understand what the issue is? In If ST sees that you are moving back and forth between contexts without actually matching anything, it skips the char and moves on to the next. It just so happens that it is skipping the char while in the |
@wbond |
Then it must be that it gives up when in the |
I think this issue is resolved. Let me know if something is unclear. |
@wbond, why is it closed? I don't think the latest version of ST has addressed it. Although my example is nonsense, I used it to illustrate a more complicated issue in the ruby syntax sublimehq/Packages#1142 (comment) is just again bug caused by a similar issue of poping look ahead pattern immediately at this line. |
This is closed because the thing you are doing is a bug. If you repeatedly push into a context and pop back out you will get into an infinite loop. So there has to be an escape hatch so you don't get stuck. The escape hatch is that if you push into a context and pop back and out again and haven't consumed anything we know that the deterministic nature of the matching rules means this will repeat forever. Instead, we consume a single char as "plain" and try to move forward. The solution is to not create a context where an infinite loop can happen. Don't push into a context and then pop back out again. At least set into two contexts where perhaps one won't match but the earlier one will. Perhaps I am misunderstanding something more subtle? |
Thanks for the detailed explanation. Indeed, this escape hatch is a nice "safety" feature. BTW, sublimehq/Packages#1142 (comment) is caused by another bug. My bad. I thought it is related to this, but it is not. Will push a fix for that soon. |
I am trying to fix this ruby bug: sublimehq/Packages#1136
After some diagnostic, the error is from this pattern.
So I extracted it to study.
Expected behavior
The letters after the slash of
/bar
will not matchActual behavior
The letters after the slash of
/bar
matchSteps to reproduce
Environment
The text was updated successfully, but these errors were encountered: