Skip to content
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

Closed
randy3k opened this issue Sep 14, 2017 · 10 comments
Closed

Popping a looking ahead pattern immediately not working #1906

randy3k opened this issue Sep 14, 2017 · 10 comments

Comments

@randy3k
Copy link

randy3k commented Sep 14, 2017

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.

%YAML 1.2
---
name: Foo

file_extensions:
  - txt

scope: text.foo

contexts:
  main:
    - match: '(?=/)'
      push: non-sense

  non-sense:
    - match: '(?=/)'
      pop: true
    - match: '.'
      scope: bar

Expected behavior

The letters after the slash of /bar will not match

Actual behavior

The letters after the slash of /bar match

Steps to reproduce

  1. First step
  2. Second step
  3. Third step

Environment

  • ST ver.: 3143
  • Platform: osx
  • Arch: x64
  • Plugin ver.: 2.25.0
  • Install via PC: True
@keith-hall
Copy link
Collaborator

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.

@randy3k
Copy link
Author

randy3k commented Sep 14, 2017

It's 5:00am my time. Have to sleep now. Will try to fix it tomorrow.

@FichteFoll
Copy link
Collaborator

I suspect some infinite loop prevention kicking in.

@wbond
Copy link
Member

wbond commented Sep 14, 2017

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.

@randy3k
Copy link
Author

randy3k commented Sep 14, 2017

@wbond
The issue is, bar is actually matched.
screen shot 2017-09-14 at 12 05 25 pm

@wbond
Copy link
Member

wbond commented Sep 14, 2017

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. 😄

@wbond
Copy link
Member

wbond commented Nov 1, 2017

I think this issue is resolved. Let me know if something is unclear.

@wbond wbond closed this as completed Nov 1, 2017
@randy3k
Copy link
Author

randy3k commented Nov 7, 2017

@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.

@wbond
Copy link
Member

wbond commented Nov 7, 2017

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?

@randy3k
Copy link
Author

randy3k commented Nov 7, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants