Not quite sure what is happening here, but looks similar to a bug that was fixed: #1190
It would presumably be best to workaround this by correcting the push pattern so that the single context pushed doesn't immediately get popped, or so that one of those patterns consumes a character.

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 main you are saying to enter the non-sense context. Then the first rule in the non-sense context is to exit if / is next. That will always be true, since the only way to enter non-sense is for / to be next.

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 main context, so bar is never matched.

@wbond
The issue is, bar is actually matched.

Then it must be that it gives up when in the non-sense context. Either way, conceptually the syntax is broken, so don't do that. 😄

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.