Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.71.2 OS Version: MAC Monterey 12.6 Steps to Reproduce: Before this last update it was common for me to use a file opened in 2 windows, "fold" the functions of window 1 and leave only what I wanted while looking for parameters or other things to use in window 2 for example in other functions. However, now if I change anything in both windows, the "cursor" jumps to where it was changed and no longer respects the "folding" in the previous window, as shown in the images below. 1 - somefunction2 window 2 - If I change something, window 1 "lose folding" previous ! 2 - somefunction1 window 2 - If I change something, window 1 "lose folding" previous ! Is there any configuration to keep the feature prior to this update? Thanks.
Yes, I can reproduce. This was an intentionally change, but we didn't think of the split screen scenario The idea is that if we detect that a folded range has gotten larger (or smaller), we expand it. FYI
Hey Thanks for the answer, do you think we will have any option to disable this change? I believe the old format helps a lot when there are multiple codes in a single file and split screen is needed.
I don't think the line you identified is the culprit here. I think this is happening because of the following code in I don't know why the test for a change in the size of the range is there. I think that just testing for would be correct. But I'm not 100% sure. Can you think of a reason for the decorated range to change which would require that we unfold? I've done a test with decRange.endLineNumber - decRange.startLineNumber !== foldRange.endLineNumber - foldRange.startLineNumber removed from that line and the split view then behaves properly, not auto-expanding things. It would be a different matter if the range returned by the folding provider changes, i.e. the test you identified. I think unfolding is correct in that situation.
Hey guys, any news? I updated to version 1.72.2 and the problem still persists, in fact this is very annoying
Nudge
are there any plans for fixing this issue? As a Vue dev, I must admit that this auto-expanding behaviour is super annoying when working with single-file-components.
I'll look at it in November.
Hi , any plans on fixing this? It is past November.
, I have updated VSCode to 1.75.1 and this is still a problem - the issue I described in is still the same. So it doesn't seem fixed.
The fix will be in 1.76

Discussion:
const foldRange = this._regions.toFoldRange(i); const decRange = this._textModel.getDecorationRange(this._editorDecorationIds[i]); if (decRange) { <del> if (isCollapsed && (isBlocked(decRange.startLineNumber, decRange.endLineNumber) || decRange.endLineNumber - decRange.startLineNumber !== foldRange.endLineNumber - foldRange.startLineNumber)) { isCollapsed = false; // uncollapse is the range is blocked or there has been lines removed or added </del> <ins> if (isCollapsed && isBlocked(decRange.startLineNumber, decRange.endLineNumber)) { isCollapsed = false; // uncollapse is the range is blocked </ins> } foldedRanges.push({ startLineNumber: decRange.startLineNumber,

}); <del> test('getRegionAtLine', () => { </del> <ins> test('getRegionAtLine2', () => { </ins> const lines = [ /* 1*/	'//#region', /* 2*/	'class A {',