Syntax Highlighting Breaks With _

[tajmone]

I've encountered problems with the following:

[NOTE]
================================================================================
You might want to output “$400” but “$4” will be interpreted as the indefinite form of the fourth parameter, as described below. So you need to use the ‘_’ to make that happen (“$_400”).
================================================================================

Where the _ in ‘_’ starts a never-ending italic styling in the highlighting, breaking the syntax highlighter from there onward.

(this issue might be related to Issue #12)

I've tried various approaches to the problem (escapes, non-curly quotes, and even `_` etc.) but either it solved the problem in ST code preview but broke the intended output, or didn't solve the problem at all.

I'll try to have a look at the syntax file myself when I find some time, but right now I'm just opening an issue to report the problem.

Most likely, the syntax definition that handles italics needs some tweaking, as that underscore should not trigger an italic style.

Also, it seems to lack bail-out fallbback checks to handle malformed code — as a general rule, syntax definitions should account for partial or malformed code, the former to handle when the user momemntarily interrupts what he was coding, leaving behind some incomplete syntax, the latter to handle malformed documents. In both cases the syntax highlighter shouldn't break so badly as to compromise the rest of the document:

• Syntax Development Tips/Advice sublimehq/Packages#757 (comment)

[alejandroschuler]

I'm having the same issue. Rather annoying!

[tajmone]

@alejandroschuler, there are some forks of this repo where the issue has been solved. Unfortunately this repository doesn't seem active, and the other repos are not officially endorsed by package.io.

I was hoping that this project becomes active again and starts accepting PRs for similar fixes and, possibly, move to ST3 (who uses ST2 anymore?). The only reason I could see for keeping the old ST2 syntax would be if some projects rely on it for syntax highlighting (eg. GitHub Linguist), but even then ... you can keep in the same ST package both the old and new syntax and ST will simply pick the right one.

One major step to start setting right this package would be to add a test suite (I'm not sure if ST2 supports them, but ST3 does), so it would be possible to pinpoint all the syntax problems and keep track of any syntax breaking changes when attempting to fix them.

But again, none of this is worth the effort unless the project is alive and open to PRs. I don't like the idea of installing forked packages (there are already too many unofficial forks of this project, each with its own fixes). It would make much more sense to integrate improvements in the upstream project instead of seeing of proliferation of unofficial packages.