New folding strategy does not fold internally indented multiline strings

[ghost]

Environment data

• Language Server version: 2022.1.1
• OS and version: MacOS
• Python version (& distribution if applicable, e.g. Anaconda): 3,10

Expected behaviour

As previous version:
Expect to be able to fold dict declaration
Expected to be able to fold inside multiline string.

Actual behaviour

The dict, which may expand thousand of lines, is not foldable.
The multiline string is just root level foldable.

Code Snippet / Additional information

"""module
  doc string.  
    more indented
"""

from json import dumps
from time import asctime

globaldict = {
    'one':1,
    'two':2,
    # ...
    'three thousands':3000
    # ...
}

Only imports and root level of docstring are foldable while dict and internal of the dostring was before.

[debonte]

@CaBazaga, thanks for reporting this. I'm curious why folding of indented sections of the doc string is desirable. Maybe there's a convention about doc string formatting that I'm not aware of related to indenting. Can you give me a real-world example where folding other than root level folding would make sense?

[ghost]

Hi @debonte thanks for the answer.

First to mention the I should have said "multiline strings" rather than docstrings, it's just it was a docstring were I noticed the were no internally folding anymore.

For the docstrings, or in general multiline strings, folding would be useful when that string is itself a formatted paragraph or doc that spawns for more than a few lines.

Sometimes I use formating, markdown / restructured, on docstrings to auto generate doc with Sphinx or similar tools.
It was useful to be able to read the headlines without the need to have the contents saving some rows on screen to fit the code while editing it.

Another example for multiline may be, for example a json, or schema, stored as a literal on a variable and written, for human readability convenience, not minimized.

It's true that the issue of not folding dicts root level is much higher, I've never had a multiline string that expands so big, but internal, indented based, folding may fit useful.

Multiline string folding is a feature I may live without but proven useful to me in the past and that I missed the same day I updated my VSCode.

The issue with Dicts root level folding seem much more prior to me, may I should have written two separate ones.

[blaylockbk]

Here is another example where code folding doesn't work as it did before...

Can't fold multi-line function arguments (per Black formatting). I miss this.

Without Pylance:

With Pylance's new code folding:

[debonte]

@blaylockbk, please file a new issue. It's hard for us to track what is fixed vs. not if a single issue has many unrelated problems in it.

[debonte]

@CaBazaga, dict folding will be fixed in our next release.

[debonte]

@CaBazaga, we're going to wait for more feedback/up-votes before acting on the "indented multiline strings" issue.

[ghost]

Seems right to me, perfect. 👍

Also noticed the dicts now folds on the root level after latest update, thanks for it. 🎉

[Irmitya]

I don't keep up with changes/updates. VSCode just updates things, and I assume everything will work as it already did.
I was writing code and noticed I couldn't fold/collapse but figured it was just the temp file I was in. I later opened an older file and when I folded everything, so I can navigate through it, I saw chunks of comments just hanging under my classes.

When I make a bunch of code then discard it, I like to leave it in place (indented) and place an explanation above it.

class null:
    def active_function():
        ...
    # Comment section
        # code to do stuff but disabled for now or ever
            # other levels of code

The current pylance collapsed active_function and ... under null but left the whole comment section unfolded.

I don't know what changes come in the updates but I do know I'd rather use the oldest version of pylance that supports this than the newest version that doesn't.

[debonte]

@Irmitya the issue you are describing is tracked by #2321

[Irmitya]

Got it.
A reddit post linked to a stackoverflow page which linked here as the problem, also specifying dictionaries but the solution (rollback pylance) worked the same for me.

I don't know what issue people are having, to specify "dictionary". Here are what I see:

1. Functions

def function(  # << not folded
    vars,  # << stopped folding in update == bad
):  # << stopped folding in update == bad
    pass  # << foldable

2. imports

from json import dumps  # << not folded
from time import asctime  # << folds in update == weird

3. Strings

""" A multiline string  # << line_a: not folded
    First indented line  # << line_b: folded
        Second indented line  # << line_c: folds only from line_a in update == bad. should fold under line_b
"""  # << line_z: I don't remember if this folded in the update

4. Indents/Comments

# Commented text  # << not folded
#     text only indented in the comment  # << not folded
    # text actually indented  # << stopped folding in update
        # sub indent of comment  # << stopped folding in update
# Last comment, like a block  # << not folded

dictionary = {  # not folded
    'one': 1,  # << folded
    'two': 2,  # << folded
    # comment  # << folded
    'three': 3,  # << only folded under the root / dictionary  == expected because it's not indented
    # comment  # << folded
        'four': 4,  # << only folded under root/dictionary in update == bad
    'five': 5,  # folded
        'six': 6,  # << only folded under root/dictionary in update == bad
}  # << not folded

1. While I prefer the old version, I try not to write functions like this, so I can live without it.
2. Collapsing non indented imports just seems arbitrary to me. It doesn't matter either way to me.
3. This makes indentations in blocks of string, arbitrary. In addition to separating text, I sometimes use a text block like a multilined comment to disable code and still fold them. This removes that ability, forcing to disable the entire code.
4. This is my core issue that I was referring to. The fact it happens at the end of code, like the issue you mentioned is coincidental. I could begrudgingly live without the dictionary part but the comment section is a non-starter for me.

[debonte]

Thanks for the detailed examples @Irmitya!

1. Functions

When we recently fixed #2269 we chose to adopt TypeScript's folding behavior. It sounds like you would like us to enable "option 3" as described in this comment. Is that correct? Could you please add a comment on that issue with your preference?

2. imports

Many languages support folding of groups of import lines. Not sure what else to say there. Obviously you can ignore it if that's not useful to you.

3. Strings

That's this issue. Thanks for upvoting. I'd love to see a real-world example where this is interesting. Either a code snippet or a link to code in some public repo.

4. Indents/Comments

Please file a new issue on folding of indented comments. A real-world example would be helpful there as well.

If you'd like your indented dictionary item scenario to be considered as well, please file a separate issue on that. I'd have to see upvotes/feedback from more users to be convinced there.

[Irmitya]

3. Strings

That's this issue. Thanks for upvoting. I'd love to see a real-world example where this is interesting. Either a code snippet or a link to code in some public repo.

I only use it as a multiline comment.
Otherwise, when placed inside functions as a description, the text is the same indentation as the d-qoutes, meaning they don't collapse separately anyway.

I use it to comment out old code, that I either don't want to delete yet or I haven't gotten around to cleaning.
As such, there's no relevant "real-world example". Just functional (or non-functional) code left in place, without being commented line-by-line or with exit codes to block from being accessed. (or rather, the d-quotes serve as the exit/skip code)

Example "times" of when I would do this, is when I wrote some code, then concluded it's a failed venture or I decided to redo it. I don't want to use comments for any reason, such as that would require selecting the code specially to keep the indentation folding, only using comments for description texts and/or non-working code, I just prefer the string color here instead of comment's.
Additionally, this could stop the code from running without adding too many lines in a commit, as would be the case for commenting every line.

[debonte]

The only remaining request here is having folding nodes for indented portions within a multi-line string.

Moving this issue to discussion as an enhancement request for comments and upvotes.