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

syntect handles push & immediately pop non-consuming patterns differently to ST #127

Closed
keith-hall opened this issue Dec 1, 2017 · 4 comments
Assignees

Comments

@keith-hall
Copy link
Collaborator

In ST, the following syntax:

%YAML 1.2
---
# See http://www.sublimetext.com/docs/3/syntax.html
name: push_pop_test
scope: source.push_pop_test
contexts:
  main:
    - match: (?=hello)
      push: test
  test:
    - match: (?!world)
      pop: true
    - match: \w+
      scope: comment.matched

accompanied by the following test passes:

# SYNTAX TEST "push_pop_test.sublime-syntax"
hello
# ^^^ comment.matched

in syntect, it doesn't:

loading syntax definitions from testdata/push_pop_test.sublime-syntax
Testing file testdata/syntax_test_push_pop_test.txt
The test file references syntax definition file: push_pop_test.sublime-syntax
-- debugging line 1 -- scope stack: ScopeStack { clear_stack: [], scopes: [] }
# SYNTAX TEST "push_pop_test.sublime-syntax"
^ +source.push_pop_test
-- debugging line 2 -- scope stack: ScopeStack { clear_stack: [], scopes: [<source.push_pop_test>] }
no operations for this line...
  Assertion selector "comment.matched" from line 3 failed against line 2, column range 2-5 (with text "llo") has scope [<source.push_pop_test>]
Ok(FailedAssertions(3, 3))
exiting with code 1

I believe this is due to how ST handles a match that:

  • consumes no characters and
  • pushes one context
  • where that context has a match which immediately pops without consuming any characters

In ST, it ignores the pop until at least one character has been consumed. Currently, syntect seems to push, then pop, then ignore the push again until at least one char has been consumed.

Related reading: sublimehq/sublime_text#1906 (comment)

This is the cause for most of the C# syntax test failures in syntect alluded to in #124 (comment) since sublimehq/Packages@e29d674#diff-9b5e53d4e14d87efc8f78017464d6b94.

@keith-hall
Copy link
Collaborator Author

I've made a PR to the Packages repo that fixes the C# syntax so that all syntax tests pass in syntect: sublimehq/Packages#1359

@trishume
Copy link
Owner

I think I also know how to fix this. I don't remember exactly, I'll have to look at the code, but syntect does something like detecting cycles, whereas it seems that Sublime just stops you from reversing direction without advancing. It should be simple to switch to the way Sublime does it.

@robinst
Copy link
Collaborator

robinst commented Apr 18, 2018

Looking into this. While reading the code and learning how it works, I've created #144 to make the main method a bit smaller and hopefully easier to understand.

robinst added a commit that referenced this issue Apr 24, 2018
This fixes issue #127. There's now 575 fewer failing assertions when
running syntest. The following test files no longer have any failing
assertions:

* syntax_test_bash.sh
* syntax_test_c#.cs
* syntax_test_C#7.cs
* syntax_test_GeneralStructure.cs
* syntax_test_Generics.cs
* syntax_test_Operators.cs
* syntax_test_Using.cs

See the added comment before ParseState for more details.
@robinst robinst self-assigned this Apr 26, 2018
@robinst
Copy link
Collaborator

robinst commented Apr 29, 2018

Fix released in 2.0.1!

@robinst robinst closed this as completed Apr 29, 2018
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

3 participants