Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[folding] Spontaneous "Unfold All" #137890

Closed
SolidStateLEDLighting opened this issue Nov 25, 2021 · 17 comments
Closed

[folding] Spontaneous "Unfold All" #137890

SolidStateLEDLighting opened this issue Nov 25, 2021 · 17 comments
Assignees
@aeschli
Labels
editor-folding Editor code folding issues on-testplan
Milestone
July 2022

Comments

@SolidStateLEDLighting
Copy link

Issue Type: Bug

I had this problem before - you guys told me that it was probably a faulty plug-in. I removed all the plugs-ins I could. The problem seemed to go away -- and now it returned -- (VS Code just updated a few days ago).

I'll be working in a large file that is mostly folded and with normal acitvity -- the code suddenly does an "Unfold All" and just opens up the entire file. This is infuritating because I have to do a "Fold All" and then open up the section that I'm working on all over again. It is a miserable bug that I don't know how to reproduce.

I only have 3 plug-ins still running:

  1. C/C++
  2. C/C++ Extension Pack
  3. Espressif IDF

There has to be a way to log a trail of activity on this to lock down the reason for this UI bug?

VS Code version: Code 1.62.3 (ccbaa2d, 2021-11-17T08:11:14.551Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

System Info
Item Value
CPUs Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz (4 x 3000)
GPU Status 2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
Load (avg) undefined
Memory (System) 15.92GB (4.24GB free)
Process Argv --crash-reporter-id 69d7eaf8-b6a9-48d5-a6a5-6a2c96b9c224
Screen Reader no
VM 0%
Extensions (3)
Extension Author (truncated) Version
esp-idf-extension esp 1.2.0
cpptools ms- 1.7.1
cpptools-extension-pack ms- 1.1.0
@PieterBranderhorst
Copy link
Contributor

I have a possible explanation of what is happening here.

When this happens do you know whether the "chevron" icons for folding also momentarily disappeared? It might be impossible to say if you don't have the "Editor: Show Folding Controls" option set to "Always".

It seems that when the folding "range provider" for the language returns a set of ranges which don't include a currently collapsed range then vscode uncollapses that range.

With the default typescript provider you can see this behaviour by opening some typescript code, folding a section of the code which doesn't include any /* or */, and then typing "/*" on a new line above the folded section. The folded section will unfold without you doing anything else.

So if a folding range provider temporarily omits some or all previously defined ranges from what it returns, folded ranges can pop back into view. In the worst case if the provider through some error occasionally returns an empty set of ranges then all current folds will be expanded.

I don't think this is desirable behaviour. Folding providers might be temporarily faked out by opening comments or quotation marks or deletions of comment ends or closing quotation marks. And they might have bugs which occasionally result in bad returned data. My preference would be that the current state of folds, i.e. the set of collapsed regions, be entirely divorced from what the folding range provider returns. Maintained separately and only uncollapsed by the user. This would create some potential conflicts when a calculated range overlaps a collapsed range but some rules of thumb could be invented to address those. On the plus side, removing a relationship between collapsed and foldable would enable adding a feature to allow users to select an arbitrary group of lines and fold them.

@aeschli
Copy link
Contributor

aeschli commented Nov 29, 2021

The example you mention (having /** but not */for a short time) is in-deed a problematic case.
Keeping the folded ranges is tricky. I'm worried it can lead to very strange folding ranges sticking around.

The current approach is to always autocomplete /** with a */, so that you don't end up commenting out a full document.

@SolidStateLEDLighting If you could pin this down to reproducible steps that would be great.

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Nov 29, 2021 via email

@aeschli
Copy link
Contributor

aeschli commented Nov 29, 2021

It could also have been caused by a slow extension startup.
When VS Code starts up, it restores all previous folding ranges and waits around 10 seconds for the extension that provided these ranges to report ranges again.
If that takes too long, we give up and unfold the ranges. The problem is that we don't know if the extension will ever come alive (maybe it was disabled/uninstalled).
The fix for that would be on the extension side, to prioritize folding range requests without waiting e.g for validation to complete.

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Nov 29, 2021 via email

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 6, 2021 via email

@Metalit
Copy link

Metalit commented Dec 16, 2021

I've been having almost this exact issue as well relatively frequently, along with being unable to find a way to reproduce it on demand. C++ also, although I have a few more extensions.

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 16, 2021 via email

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 16, 2021 via email

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 16, 2021 via email

@PieterBranderhorst
Copy link
Contributor

That the problem happens after switching back to the code from another file is significant. That's a time when collapsed state information is reloaded from a save area and then resynchronized with the folding range provider. (C++ specific extension in this case.)

It seems to me that the key to the problem is that vscode discards collapsed regions when they aren't present in a set returned by the range provider. That could be triggered by a bug in either vscode or the range provider. Perhaps a subtle timing bug. Regardless of the exact cause I think the solution should be to hold onto already collapsed regions regardless of what the range provider returns.

I understand the concern about that being tricky. But not doing it seems wrong. Not just for this case and not just to allow for errors in range providers. Even when there are no bugs the current approach causes all collapsed regions below a line where we temporarily delete an end-of-comment to unfold.

I'm not on the vscode team. But I'm digging into the code to see if I can propose a fix which Microsoft might accept. I'm thinking that it will include adding a small checksum to folding memento's to ensure that what gets collapsed on restarts is what the user intended.

@aeschli
Copy link
Contributor

aeschli commented Dec 17, 2021

So yes, I suspect it's the cpp folding provider not being consistent, or too slow. Adding traces could be a first good step to understand that.
@PieterBranderhorst Your help is very welcome and if you want to give it a try with keeping the folded ranges longer, I'd love to see such a solution

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 18, 2021 via email

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 20, 2021 via email

@PieterBranderhorst
Copy link
Contributor

@aeschli I'm working on it. Of course this won't fix the underlying issue which is probably in the C++ range provider but it will make vscode's folding tolerant of such issues in range providers. I'm adding a command (ctrl K + ctrl .) to fold a selected range of lines at the same time rather than later because it will make testing this change easier.

@SolidStateLEDLighting
Copy link
Author

SolidStateLEDLighting commented Dec 22, 2021 via email

@PieterBranderhorst
Copy link
Contributor

I've finished code which should fix this issue and have submitted a pull request.

@aeschli You can look at the code I'm proposing in #139779.

@PieterBranderhorst PieterBranderhorst mentioned this issue Jan 19, 2022
Closed
@aeschli aeschli mentioned this issue Jun 7, 2022
Closed
@aeschli aeschli changed the title Spontaneous "Unfold All" [folding] Spontaneous "Unfold All" Jun 8, 2022
@aeschli aeschli added the editor-folding Editor code folding issues label Jun 8, 2022
@aeschli aeschli mentioned this issue Jun 13, 2022
Closed
@aeschli aeschli mentioned this issue Jul 25, 2022
Closed
2 tasks
@aeschli aeschli added this to the July 2022 milestone Jul 25, 2022
@aeschli aeschli closed this as completed Jul 25, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Sep 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@aeschli aeschli

Labels
editor-folding Editor code folding issues on-testplan
Projects
None yet
Milestone
July 2022
Development

No branches or pull requests
4 participants
@aeschli @SolidStateLEDLighting @Metalit @PieterBranderhorst