You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Incorrect indentation after string literals containing escaped characters #4241
Extension version (available under the Extensions sidebar): 2019.1.0
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): 3.7
Type of virtual environment used: N/A
Relevant/affected Python packages and their versions: none
Logs
Console:
Starting Jedi Python language engine.
Linter 'pylint' is not installed. Please install it or select another linter".
Error: Module 'pylint' not installed.
changed the title [-]Incorrect indentation after string literals containing newline[/-][+]Incorrect indentation after string literals containing escaped characters[/+]on Jan 31, 2019
Yeah, this is really annoying. It seems like this was introduced by the "fix" for #3284.
If I had to choose between having line continuation backslashes work properly, or backslash escapes work properly, I would choose backslash escapes in a heartbeat. Some people probably never use backslash for line continuation, while most other people probably use it very sparingly, since PEP 8 encourages implicit line continuation wherever it can be sensibly applied.
And even if you like backslash line continuation, (1) presumably you're not going to have large sections of code riddled with them, since long lines are discouraged anyway, and (2) you have reasonable alternatives for achieving what you need. Whereas there are plenty of situations where you could be using a lot of backslash escapes (strings, regular expressions), and there is no reasonable alternative.
It seems like such a simple and easy fix (see my comment on #5821, which perhaps should gave gone on #3915). If we are wrong about this, and it's actually more complicated, then I wish they would come out and explain why.
Activity
caudate-julie commentedon Jan 31, 2019
I am not familiar with the code, but it may be this string:
https://github.com/Microsoft/vscode-python/blob/c23603c9b7a3dbb805e8339a2d7cf01bb7327b34/src/client/extension.ts#L176
since regex doesn't include end of line.
[-]Incorrect indentation after string literals containing newline[/-][+]Incorrect indentation after string literals containing escaped characters[/+]jkyeung commentedon Mar 9, 2019
Yeah, this is really annoying. It seems like this was introduced by the "fix" for #3284.
If I had to choose between having line continuation backslashes work properly, or backslash escapes work properly, I would choose backslash escapes in a heartbeat. Some people probably never use backslash for line continuation, while most other people probably use it very sparingly, since PEP 8 encourages implicit line continuation wherever it can be sensibly applied.
And even if you like backslash line continuation, (1) presumably you're not going to have large sections of code riddled with them, since long lines are discouraged anyway, and (2) you have reasonable alternatives for achieving what you need. Whereas there are plenty of situations where you could be using a lot of backslash escapes (strings, regular expressions), and there is no reasonable alternative.
jkyeung commentedon Jun 12, 2019
I'm pretty sure you've hit the nail on the head.
It seems like such a simple and easy fix (see my comment on #5821, which perhaps should gave gone on #3915). If we are wrong about this, and it's actually more complicated, then I wish they would come out and explain why.
karrtikr commentedon Jun 26, 2019
Prescribed Solution:
beforeTextsetting to use the below regex:There may be a more correct regex to use:
/^(?!\s+\\)[^#\n]+\\$/See #5821 (comment).
Make sure this does not break the following (from #3284):
Add unit tests (will conflict with microsoft#4241)
ericsnowcurrently commentedon Jul 9, 2019
I've verified that the following indent/dedent properly:
Add regex to dedent `else` and friends (#6497)