jiebi/CodeConvo huggingface dataset:
Code change:
let foldersToRestore: URI[] = []; let workspacesToRestore: IWorkspacePathToOpen[] = []; if (openConfig.initialStartup && !openConfig.cli.extensionDevelopmentPath && !openConfig.cli['disable-restore-windows']) { <del> let foldersToRestore = this.backupMainService.getFolderBackupPaths(); foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </del> <ins> // don't restore backuped folders, for #92318. // let foldersToRestore = this.backupMainService.getFolderBackupPaths(); // foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </ins> // collect from workspaces with hot-exit backups and from previous window session workspacesToRestore = [...this.backupMainService.getWorkspaceBackups(), ...this.workspacesMainService.getUntitledWorkspacesSync()];

Related discussion:
text: I think you're describing the designed behavior, I mean to ask about the behavior to 1.43 so that it's clear how having caused the backups to behave and why backups stacked up not getting restored (was this because they weren't being saved to anymore?).
I think can comment if there was some intention behind the change or just an oversight. To be clear: I would never expect a folder with backups to be to a workspace to turn it into a multi-root workspace.
One thing might be considered, as discussed with in Gitter, is to limit the number of windows/workspaces to be restored upon start, such as 10 at most, which might relieve this "correction".
We decided to fix this by reverting the change and no longer restore the folders with unsaved content. That was the behavior from 1.32 to 1.42 and as we didn't get any complaints, this seems to be practical. You can always open these folders from the recent menu, and unsaved content is restored. I created as a followup issue for the next milestone. We plan to also no longer restore workspaces (except unsaved/untitled workspaces) and we will add more information to the recent menu to show which folders/workspaces have unsaved content.
To verify: set open 2 windows, each opened on a folder. Make a unsaved change or add a untitled file with content close both windows. There should be no questions asked, exit VSCode open VSCode on an other folder (). Only one window should appear
Code change:
import * as perf from 'vs/base/common/performance'; import { WorkbenchActionExecutedEvent, WorkbenchActionExecutedClassification } from 'vs/base/common/actions'; import { memoize } from 'vs/base/common/decorators'; <del> import { IFilesConfiguration, ExplorerFolderContext, FilesExplorerFocusedContext, ExplorerFocusedContext, ExplorerRootContext, ExplorerResourceReadonlyContext, ExplorerResourceCut, ExplorerResourceMoveableToTrash, ExplorerCompressedFocusContext, ExplorerCompressedFirstFocusContext, ExplorerCompressedLastFocusContext, ExplorerResourceAvailableEditorIdsContext, VIEW_ID, VIEWLET_ID, ExplorerResourceNotReadonlyContext, ViewHasSomeCollapsibleRootItemContext } from 'vs/workbench/contrib/files/common/files'; </del> <ins> import { IFilesConfiguration, ExplorerFolderContext, FilesExplorerFocusedContext, ExplorerFocusedContext, ExplorerRootContext, ExplorerResourceReadonlyContext, ExplorerResourceCut, ExplorerResourceMoveableToTrash, ExplorerCompressedFocusContext, ExplorerCompressedFirstFocusContext, ExplorerCompressedLastFocusContext, ExplorerResourceAvailableEditorIdsContext, VIEW_ID, VIEWLET_ID, ExplorerResourceNotReadonlyContext, ViewHasSomeCollapsibleRootItemContext, ExplorerViewletVisibleContext } from 'vs/workbench/contrib/files/common/files'; </ins> import { FileCopiedContext, NEW_FILE_COMMAND_ID, NEW_FOLDER_COMMAND_ID } from 'vs/workbench/contrib/files/browser/fileActions'; import * as DOM from 'vs/base/browser/dom'; import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService';

Related discussion:
text: Now I'm at work (both are Windows machines, VSCode up to date), and I went to try your approach. However, I have a lot of menus in my secondary sidebar, so I didn't want to on my main profile, so I did the following: Ensure my workaround from before is commented out Export the profile as Import the profile Switch to that profile Verify that the key doesn't work First, try the less invasive, right-click on Explorer button in secondary sidebar and click key, and others, works again, even when putting the Explorer back in the secondary sidebar Curiously, switching back to the profile, the key, and others, works again, even when putting the Explorer back in the secondary sidebar Never had to go the nuclear option and So, some funny business related to one of the steps above, probably the settings profile shuffle, restored basic functionality of those keys, without having to manually tweak the expressions as before, and without having to go nuclear and . It's possible to work around this with some UI shuffling, but your mileage may vary. My initial request to backport the patch to stable VSCode is not so serious since there are a few workarounds documented here. Also, thanks for the quick work in the PR! I'm looking forward for this behavior to stabilize in future versions, since secondary sidebar Explorer view (without the compromise of moving the whole primary sidebar over) is great!
Code change:
import * as perf from 'vs/base/common/performance'; import { WorkbenchActionExecutedEvent, WorkbenchActionExecutedClassification } from 'vs/base/common/actions'; import { memoize } from 'vs/base/common/decorators'; <del> import { IFilesConfiguration, ExplorerFolderContext, FilesExplorerFocusedContext, ExplorerFocusedContext, ExplorerRootContext, ExplorerResourceReadonlyContext, ExplorerResourceCut, ExplorerResourceMoveableToTrash, ExplorerCompressedFocusContext, ExplorerCompressedFirstFocusContext, ExplorerCompressedLastFocusContext, ExplorerResourceAvailableEditorIdsContext, VIEW_ID, VIEWLET_ID, ExplorerResourceNotReadonlyContext, ViewHasSomeCollapsibleRootItemContext } from 'vs/workbench/contrib/files/common/files'; </del> <ins> import { IFilesConfiguration, ExplorerFolderContext, FilesExplorerFocusedContext, ExplorerFocusedContext, ExplorerRootContext, ExplorerResourceReadonlyContext, ExplorerResourceCut, ExplorerResourceMoveableToTrash, ExplorerCompressedFocusContext, ExplorerCompressedFirstFocusContext, ExplorerCompressedLastFocusContext, ExplorerResourceAvailableEditorIdsContext, VIEW_ID, VIEWLET_ID, ExplorerResourceNotReadonlyContext, ViewHasSomeCollapsibleRootItemContext, ExplorerViewletVisibleContext } from 'vs/workbench/contrib/files/common/files'; </ins> import { FileCopiedContext, NEW_FILE_COMMAND_ID, NEW_FOLDER_COMMAND_ID } from 'vs/workbench/contrib/files/browser/fileActions'; import * as DOM from 'vs/base/browser/dom'; import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService';

Related discussion:
text: mac select an entry in the explorer press to trigger rename the file is being opened, no rename log
tested on windows and this doesn't work for me - not sure if it's necessarily platform specific
Steps to verify explorer that keybindings still work for the explorer
Mac Pro (Intel 2019) user here. I also have the same problem. Before pressing can rename files but now it just navigates to the file editor window.
This will be fixed in the next release which comes out sometime this week. In the meantime -should fix it for you.
Thank you for prompt reply. Yes, it works fine now!!
Code change:
private readonly recommendationsByPattern = new Map<string, IStringDictionary<IFileOpenCondition[]>>(); private readonly fileBasedRecommendations = new Map<string, { recommendedTime: number }>(); private readonly fileBasedImportantRecommendations = new Set<string>(); <del> private readonly processedFileExtensions: string[] = []; </del> get recommendations(): ReadonlyArray<ExtensionRecommendation> { const recommendations: ExtensionRecommendation[] = [];

Related discussion:
text: When a user opens a file extension that does not have a specific recommendation tied to it, we show the general notification that points users to the marketplace. This has the following flaws: Most popular file types are already covered by specific extensions, so what gets left in this experience is leftovers For most of the extensions there is no good extension to handle this experience. Thus opening the Extension page does not provide value This is adding un-needed pings to the Marketplace service Also we had a bug that this feature was not available in stable and only 3 users found it is not there Would love for us to get some telemetry on this actions to see if this is actually bringing value to users. If not, we should either: Remove this flow completely Have a pre-defined set of file extensions for which we show this. Checking with tags seems to be very faulty. In my example below there is not an extension that helps with PowerPoint files. !
Only of these notifications end up with users clicking on Search Marketplace ! When it is actually clicked here are the top extensions ! Thus I suggest that we: Remove this dialog Add explicit extension recommendation for and . Since those seem to be missing. what do you think?
Sounds good to me
Great. Ok, you remove the dialog when you find time, I will add the recommendations for csv and pdf. Or if you go on vacation, I can also remove the dialog. I am working in August. Thanks
Feel free to remove it in August, otherwise I can also do it in September. Here it is
To verify: a file with some strange extension. For example -make sure no notification shows up a .py file or .go file. Make sure you get an extension recommendation for specific python / go extensions
Code change:
import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { INotebookService } from 'vs/workbench/contrib/notebook/common/notebookService'; import { URI } from 'vs/base/common/uri'; <del> import { IWorkingCopyService, IWorkingCopy, IWorkingCopyBackup } from 'vs/workbench/services/workingCopy/common/workingCopyService'; </del> <ins> import { IWorkingCopyService, IWorkingCopy, IWorkingCopyBackup, WorkingCopyCapabilities } from 'vs/workbench/services/workingCopy/common/workingCopyService'; </ins> import { basename } from 'vs/base/common/resources'; import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { IBackupFileService } from 'vs/workbench/services/backup/common/backup';

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- Version: 1.46.0-insider Commit: Date: 2020-06-01T10:32:27.369Z Electron: 7.3.0 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.5.0 Steps to Reproduce: a new untitled notebook (using VS Code Python extension) you add a cell or the like, then VSC will invoke the save method on the Problems Adding cells should not invoke save (this happens when user has auto save turned on) Errors thrown in the method are ignored. VSC will assume the notebook was saved and mark it as not dirty (the dirty indicator doesn't exist on the tab anymore) I don't think VSCode should call the method for untitled notebooks. FYI - We create untitled notebooks with a scehme . If this isn't the way to indicate an untitled file (scheme), we might need some API or the like in the notebooks implememtation. /cc
Good catch, untitled file should not trigger save until users explicitly run Save, which will invoke SaveAs.
We should also improve the overall experience for creating untitled notebook documents, they can be created in two approaches: Users press cmd/ctrl+n to create an untitled file, switch to another view type (tracked in ) Users run a specific command to quickly create a notebook untitled file. command should take view type as arguments. cc we may also want to adopt this in Custom Editor world.
We now support opening a untitled file with specified editor view type through the existing new untitled file command (in master, and tomorrow's Insiders) When the command is executed, is invoked with an URI with scheme. is invoked only when users save so no auto save for untitled files as usual.
Code change:
}, { type: 'array', <del> items: { type: 'string' }, </del> <ins> prefixItems: [ { type: 'string', enum: ['absolute', 'relative', 'autoDetect', 'search'] }, ], minItems: 1, maxItems: 1, additionalItems: false }, { type: 'array', prefixItems: [ { type: 'string', enum: ['relative', 'autoDetect'] }, { type: 'string' }, ], minItems: 2, maxItems: 2, additionalItems: false, </ins> examples: [ ['relative', '${workspaceFolder}'], ['autoDetect', '${workspaceFolder}'],

Related discussion:
text: Type: <bBug</bSteps to reproduce: a fresh, vanilla VS Code Insiders installation without any extensions. and open a new folder. , open it, and save it with the following contents: Actual results: A warning is reported in Problems tab and via yellow squiggles at line 10, column 25 (= character of the line specifying the ): Expected results: No warning is reported. Additional information: The problem matcher has been copied directly from the (). VS Code should not display warnings for unmodified examples from the docs. This also occurs in the current non-insiders release 1.74.0. VS Code version: Code - Insiders 1.75.0-insider (, 2022-12-08T05:20:51.149Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I can repro this. probably caused by your changes to the schema - could you pls take a look?
Of course. I'll submit the fix.
The PR is ready for review.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified Thanks for the quick fix!
Code change:
} } try { <del> // Variable substitution can require user interaction, so only one of these should be running at a time. return this.variableSubstitutionQueue.queue(() => dbg.substituteVariables(folder, config)); </del> <ins> return await dbg.substituteVariables(folder, config); </ins> } catch (err) { this.showError(err.message, undefined, !!launch?.getConfiguration(config.name)); return undefined;	// bail out

Related discussion:
text: <!-- 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.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.
Code change:
} } try { <del> // Variable substitution can require user interaction, so only one of these should be running at a time. return this.variableSubstitutionQueue.queue(() => dbg.substituteVariables(folder, config)); </del> <ins> return await dbg.substituteVariables(folder, config); </ins> } catch (err) { this.showError(err.message, undefined, !!launch?.getConfiguration(config.name)); return undefined;	// bail out

Related discussion:
text: I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.
Code change:
} } try { <del> // Variable substitution can require user interaction, so only one of these should be running at a time. return this.variableSubstitutionQueue.queue(() => dbg.substituteVariables(folder, config)); </del> <ins> return await dbg.substituteVariables(folder, config); </ins> } catch (err) { this.showError(err.message, undefined, !!launch?.getConfiguration(config.name)); return undefined;	// bail out

Related discussion:
text: As an easy workaround, I can put a queue around calling into the vscode variable resolver and calling an extension debug config provider. But, putting a queue around two unrelated pieces of code seems to say that I'm solving the problem at the wrong level.
Or maybe make them the same level by moving the resolve queue to
Just to be clear. The two callers of the are in two different places right (core and extension)?
Right
Ok I've not heard of any feature request like this but feel free to open one... I wonder if maybe instead Core could have concept of "important" quick picks that can't be stomped over by extensions and instead the extension calls wait until Core is done. Then we don't need any more API
It can also go the other way. The problem is just that there are two async processes that have to run and show a quick input, and we need both of them to complete and not to get canceled by the other. Filed I'll go with a workaround for now, so I'm not blocked, just figured I'd start the discussion
Sorry for the late reply. I tested this today and it works for our scenario. Thanks for the quick fixes!
Code change:
{ "command": "git.undoCommit", "title": "%command.undoCommit%", <del> "category": "Git" </del> <ins> "category": "Git", "enablement": "!commitInProgress" </ins> }, { "command": "git.checkout",

Related discussion:
text: Testing Currently the "Undo last commit" command has not effect while the commit editor is open. It should either: disabled enabled and on execution close the editor and abandon the current commit I think option 1 is better !
Part of disablement revamp effort:
It also shows up in command palette !