TypeScript
TypeScript copied to clipboard
[typescript] removing a bracket loses all folded areas
TS Template added by @mjbvz
TypeScript Version: 4.1.0-dev.20201002
Search Terms
- folding / folds
- getOutlineSpans
(see my comment for a self contained example)
- VSCode Version: 1.47.0
- OS Version: Windows 10 Verison 1909
Steps to Reproduce:
- make an error on the code with all lines collapsed.
- It will automatically expand all the codes. Which is annoying. Bcuz I have to collapse it automatically.
Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:
Can you add more detailed steps and and a specific code example? We only expand folded regions if the cursor has been placed in a folded regions or of a code change causes the regions to go away (e.g. by opening a string or comment)
It's actually the code. If I am typing something that the program changes the colour of the code below, the collapsed code will be expanded automatically. Which is annoying.
Do you have a small code sample so I can investigate?
I can send you a video if you want
but where do I drop it?
You can attach files to the issue with drag & drop
Doesn't support videos. I will zip the file.
VSCode Problem.zip Here^ Extract it
The zip file seems to be invalid...
https://youtu.be/Vo6x6i-iIhE try this
Thanks that worked, thanks for the video. The problem is that by deleting a closing bracket, the TypeScript parser can not properly parse the content and can no longer find the same blocks as before. So the folding regions are not reported and we have to unfold them.
It's a difficult problem which, IMO, must be solved with error recovery in the TS parser.
Self contained example:
- For the file:
{
console.log('abc');
}
- Fold the block
- At the start of the file, type
<
or(
Bug This results in the code unfolding since TS returns a new set of folding ranges.
Perhaps we can handle folding ranges more gracefully in cases like this. The other option would be that TS somehow signals to VS Code that we should keep using the old folding ranges. Right now we don't have enough info on the VS Code side to know that the newly returned folding ranges will cause unexpected behavior
Maybe if a change results in both 1) the removal of a folding range that’s currently folded, and 2) a syntax error that intersects that range, you could leave it intact? Not sure if you’d have to throw out our entire response of new folding ranges or if it would sometimes be possible to merge them. When you request folding ranges, do you already have syntactic diagnostics? The immediate problem I see with calculating all this on our side is that by the time you ask for new folding ranges, we no longer know what the old ones are (not to mention, we don’t know what regions have been folded, and all this is irrelevant if the user isn’t folding anything).