Continuing strs when broken across lines

Love the extension. Thanks for the work.

It would be great if str literals could be continued when broken across lines.

I had a line of code Like this:

my_str = f"{steps: >5d}    3    1    3    0{nodes: >5d}{elements: >5d}{boundaries: >5d}{materials: >5d}{optional(interfaces, ' >5d'):s}    1"

...and (with the help of Python Indent) reformatted it like this:

my_str = (f"{steps: >5d}    3    1    3    0"
          f"{nodes: >5d}{elements: >5d}"
          f"{boundaries: >5d}{materials: >5d}"
          f"{optional(interfaces, ' >5d'):s}    1")

A cool feature would be to have the quotation marks (with preceding f) automatically inserted.

Interesting idea, thanks for posting. So you're thinking something like this?

# | indicates cursor location

# case 1, no f-string
s = "really long| string"

s = ("really long"
     "| string")

# case 2, f-string
s = f"another {really} long| string"

s = (f"another {really} long"
     f" string")

# note that r, u, rf, fr, b, rb, and br are all allowed prefixes
# and should be handled in the same way as f-strings

I don't remember if the python parser picks up on whether the string was prefixed with anything, but would probably not be terrible to add if not.

Reading back through the parsing code I wrote, I'd have to add another tracker for any combination of f, r, u, rf, fr, b, rb, and br and keep it on hand if the next character turns out to start a string. The output of that parsing function would have to be updated with this information, as well as the string delimiter (', ", ''', """).

That's pretty much what I had in mind! Thanks for taking it under consideration.

If it makes it less complicated I would not necessarily consider adding the parentheses around the string as a "must have"... after all it is really easy to add parentheses around an expression by selecting it and hitting ( already.

So maybe the behavior should be like:

# | indicates cursor location

# case 1, no parentheses => no change in behavior
s = "really long| string"

s = "really long
     | string"

# case 2, after adding parentheses => change in behavior
s = ("really long| string")

s = ("really long"
     "| string")

I looked into this a little more, and concluded that this would require a moderate change to the parser to keep track of what column the string started on.

Thanks for looking into it. "Moderate" sounds like a decent amount of effort would be required.

I think the crux of it would be adding several new pieces of information to the current parser. This is what it currently outputs:

export interface IParseOutput {
    canHang: boolean;
    dedentNext: boolean;
    lastClosedRow: number[];
    lastColonRow: number;
    openBracketStack: number[][];
}

We'd need to add a something to track what column the string delimiter was on (null if we're not in a string), what the string delimiter was (so we know to add a single or double quote), whether the string had any prefixes (u, f, etc.), and possibly whether we're within a closing parentheses. So the interface would end up looking something like this:

export interface IParseOutput {
    canHang: boolean;
    dedentNext: boolean;
    lastClosedRow: number[];
    lastColonRow: number;
    openBracketStack: number[][];
    // Additional items
    currentStringDelimiter?: string;
    stringStartColumn?: number;
    stringPrefix?: string;
    insideParentheses: boolean; // maybe
}

Does the plugin have to handle undo on its own, or is that taken care of by VSCode?

The edits are bundled into a single "transaction" so that VSCode groups them into a single undo/redo action

I would like to know if this feature has already been implemented in the extension?

pycharm does something very similar.

Navigation Menu

Repository navigation

Continuing strs when broken across lines #69

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Continuing strs when broken across lines #69

Description

Activity

kbrose commented on Oct 6, 2020

kbrose commented on Oct 6, 2020

Ricyteach commented on Oct 6, 2020

kbrose commented on Oct 21, 2020

Ricyteach commented on Oct 21, 2020

kbrose commented on Oct 21, 2020

Ricyteach commented on Oct 21, 2020

kbrose commented on Oct 27, 2020

Marcosalen commented on Aug 16, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions