Packages: Python Multi Line Highlighting does not work with \ character

[SanketSabnis]

The \ should be detected as a special character for multi line strings.
This is an issue with the latest Sublime Text 3 3114 build.

In Sublime Test 2:

This issue is hard to work around as it messes up all subsequent lines and highlighting.

[crcornwell]

Also having this issue.

[lee00678]

same here.

[keith-hall]

I have made a PR which includes a fix for this

[smakhtin]

Having the same issue, merge please.

[MattDMo]

Just as a reminder for everyone, please use Github's new Add your reaction feature instead of filling up everyone's notification stream with "_I'm having the same issue here as well_" comments. To use it, click on the +:grinning: smiley icon in the gray bar at the top right of a comment, and pick from the selection of emoji (in this case the :thumbsup: thumbs up would do perfectly). This gets your point across, and doesn't give everyone associated with an issue (including all the invisible subscribers like me) yet another notification _and_ email to process.

Thanks!

[MattDMo]

On the topic of this particular issue, the pedantic me would like to point out that PEP-8 discourages the use of \ for line continuation:

The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. _These should be used in preference to using a backslash for line continuation._

(emphasis mine) except under certain circumstances:

Backslashes may still be appropriate at times. For example, long, multiple with -statements cannot use implicit continuation, so backslashes are acceptable:

with open('/path/to/some/file/you/want/to/read') as file_1, \
     open('/path/to/some/file/being/written', 'w') as file_2:
    file_2.write(file_1.read())

Another such case is with assert statements.

Make sure to indent the continued line appropriately.

Of course, this bug _does_ need to be fixed, but it shouldn't pop up that often if you're coding correctly :wink: Perhaps @keith-hall can add a look-behind so that the fix only works on lines beginning with with or assert...

[keith-hall]

@MattDMo we are trying to avoid the use of lookbehinds, because the new regex engine doesn't support them. Therefore, using them will give reduced performance. Also, as the line continuations are legal, probably they should be marked as depreciated if anything, but such things should really be picked up by a linter plugin IMO so users can customize what warnings they get.

[MattDMo]

Sorry, I keep forgetting that sarcasm doesn't communicate well in plain text. But at any rate, is there some place where I could find specs on the new regex engine? Is it still Oniguruma-based, or PCRE, or Python re, or what? I've been following the issues and PRs here with varying degrees of attention, so I don't have a full picture yet.

[keith-hall]

@MattDMo I highly recommend reading Will's post here: https://forum.sublimetext.com/t/whats-sublimes-new-regex-engine/18944/3

[wbond]

For the current truth, the Regex Compatibility variant of the Syntax Tests build system should be used. The regex engine is being slowly improved as we find bugs or features that we missed that reasonable to implement.

[keith-hall]

I guess that means we should keep a syntax definition that contains all possible regex constructs and run the Regex Compatibility variant of the Syntax Tests build system each time a new ST3 build is released*, to know what features are now supported that previously were not, such that we can then look for opportunities to improve/simplify syntaxes that have been made compatible with a reduced feature set...

* or at at least when the release notes mention:

Package Development: Expanded the set of regexes the new regex engine is able to handle