-
Notifications
You must be signed in to change notification settings - Fork 115
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
anchor operation seems sparadic past first repetition on a line. #70
Comments
Have you tried cloning this repository, running It is a good tool that explains how states are pushed and popped and why. Here is the output for your test case: OUTPUT
|
The output fails to tell me 'why' So, I forked, downloaded, and attempted to build, fixed prerequisites to the prerequisites, then fixed issues with the prerequisites, finally got a build, and finally got an output. Added to the '@@ScanNext' logging, the anchor position, and confirmed that the anchor is where I think it is. So all of this does not explain why the matching against the anchor isn't working. However, I removed the comment marks in front of the debug: (grammer.ts: matchRule) console.log(' scanning for');
console.log(debugCompiledRuleToString(ruleScanner)); and this shows me something interesting. For some reason, in the matches, the \G is being changed to Also, notice on the end of many lines, that the last 2 tokens processed are |
The rule is not corrupted. When IMHO the explanation I have provided here for
I will investigate if you can demonstrate a clear issue: a grammar, a body of text, and tokenization results in TextMate (expected) that are different than the ones in vscode-textmate (actual)? |
Please excuse me for an error I made. While the 'change of the G (or A) to a uFFFF' is pretty clear in the code, for some reason when I was looking at the log, I swear I saw the G translation at points where it shouldn't have occurred, but looking again (and not from a new run either, its still the same run) that's not true. SO that means my real issue still stands. \G isn't reliably working!
This particular rule is failing on two counts.
Instead, rule -1 matched at position 15. Something is wrong. Here is nearly exactly the same match scenario, one line up, and it worked correctly.
In both cases, the anchor should have matched and the negative lookbehind should have failed, so both matches should have occurred based solely on the anchor. |
Regarding the extra console.log(`@@scanNext ${linePos},{${anchorPosition}}: |${lineText.content.replace(/\n$/, '\\n').substr(linePos)}|`); The replacement changes the length of the string so that linePos isn't really valid, at least past that '\n'. These only occur when the last token on a line is matched (probably most specifically by a beginEndRule), but doesn't include the newline (\n), A rule pop occurs at after the newline, and then one more match is attempted with an empty remaining string. |
I confirm, there is a bug. Thank you for following through and for your patience! It is shown here indeed:
That is correct. The root cause is caching in i.e. the root cause is that |
@msftrncs I've created atom/node-oniguruma#87 and a PR to fix it atom/node-oniguruma#88 Once Thank you! |
This has been fixed upstream and adopted in vscode via microsoft/vscode@f1f688c Tomorrow's insiders build will have the fix. |
@alexandrudima , confirming that I have tested an insiders build and my concept for matching PowerShell operators immediately after variables (relying on the \G) is now working. Thank-you. |
Regarding microsoft/vscode#57831, using VS Code 1.27.2,
syntax (JSON) as simplified:
applyEndPatternLast was an experiment. Had no affect as either 1 or "1" or not present.
A test set as
A variable that starts the line can always match the operator immediately behind it, but after that, I cannot seem to find a reason for why it sometimes matches, sometimes doesn't. It specifically deals with the operators that, if they were immediately following a command name, would be possibly an extension of the command name, so a lookbehind is used to verify the last digit isn't alpha, when in reality, what needs to be checked is the last scope, so I am trying to use the anchor \G (as an alternate), as all these operators can immediately follow a variable. I have been looking for a way to support the operators following items where the '-' is a separator, so that a space is not required (since PowerShell doesn't require a space). I have more ideas how to handle this, but I really think there is something going wrong with the rule parsing, probably around the anchor. I'll probably try separating the operators from the lookbehind, so that in this case, I can just recursively call the base operators, but please keep in mind I am just editing the original VS Code language file attempting to make it work better.
Unexpectedly the scope 'meta.test' is showing up on the spaces after the variable matches, and on the failed operator matches, the 'meta.test' scope shows up on the '-' only. However, if I change the end match to
(?=.|$)
then that doesn't happen, but everything is still exactly the same for the matching of the operators. Interesting note, when it normally works, the operator immediately following the variable will be included in 'meta.test' as expected, but when a part that isn't working, is edited (remove spaces from places on the same line) and suddenly starts working, the operator matches that suddenly start working are NOT in the 'meta.test' scope as it would have been expected!The text was updated successfully, but these errors were encountered: