jiebi/CodeConvo huggingface dataset:
Code change:
if (toggleData && groups.filter(g => g.extensionInfo).length) { for (const key in toggleData.settingsEditorRecommendedExtensions) { const extension = toggleData.recommendedExtensionsGalleryInfo[key]; <del> const manifest = await this.extensionGalleryService.getManifest(extension, CancellationToken.None); </del> <ins> let manifest: IExtensionManifest | null = null; try { manifest = await this.extensionGalleryService.getManifest(extension, CancellationToken.None); } catch (e) { // Likely a networking issue. // Skip adding a button for this extension to the Settings editor. continue; } </ins> const contributesConfiguration = manifest?.contributes?.configuration; let groupTitle: string | undefined;

Related discussion:
text: made no difference made no difference is set, but I doubt I want to uncheck it if I understand it correctly. is set to override (default), and it sounds like it only affects extensions, so I didn't touch it. I don't see any option to manually add a certificate anywhere in the settings.
Based on I found that does work. That is a bit of a sledgehammer though, and not really an ideal (or even slightly secure) solution.
The Settings editor currently recommends the Copilot extension when it's not installed, which lines up with the error messages you're seeing. I'll put up a PR that skips over showing that feature in case of networking errors.
Tomorrow's should contain the fix.
what about the bit where it seems to ignore the root system certificates though? It seems there were actually (at least) two bugs here: one you fixed, where settings can't open when there are network errors fact that a corporate proxy with correctly installed CA certificates in the system store doesn't work. Presumably it isn't picking up the system CA certificates correctly.
thank you very much my problem is solved after follow this step (Open VS Code disable all extensions disabled, and enable once again all extension then i am successfully able to see my settings))
Please see on how to add a root certificate for Chromium, that also applies for Electron-based applications like VS Code. The root certificate example is:
Thanks this works. I thought I had already it, since I it in Chromium. But of course on Ubuntu Chromium runs in a snap by default, so it didn't use the same store as VSCode...
Code change:
rows }; <del> this._ptyProcess = pty.spawn(shellLaunchConfig.executable, shellLaunchConfig.args, options); </del> <ins> try { this._ptyProcess = pty.spawn(shellLaunchConfig.executable, shellLaunchConfig.args, options); } catch (error) { // The only time this is expected to happen is when the file specified to launch with does not exist. this._exitCode = 2; this._queueProcessExit(); return; } </ins> this._ptyProcess.on('data', (data) => { this._onProcessData.fire(data); if (this._closeTimeout) {

Related discussion:
text: VSCode Version: Code 1.14.2 (, 2017-07-19T23:34:09.706Z) OS Version: Windows_NT ia32 10.0. Extensions: ExtensionVersion ------ cpptools0.12.1 csharp1.11.0 Steps to Reproduce: an empty folder with VSCode a new MSBuild task building (execute task) Expected: Fails gracefully somehow Actual: Just spins forever and never dies until I manually kill the task. Note: this also happens when I mistype a path or something in the command to a directory that say for example doesn't exist. If the command is wrong in some way, the task will just spin forever. <!-- Launch with to check. --Reproduces without extensions: Yes/No
The terminal doesn't send an onExit or any other event in this case so that the task system could determine that the process has finished / died. Steps to reproduce: Windows, no msbuild installed fresh workspace configure task runner select MSBuild from the list of templates F1 Run Task Select Build Observe: the spinner never stops. Could can't even terminate the task. The reason is that the shell actually fails to execute msbuild however the terminal never send an onExit event. Look at the process explorer there is a lingering vscode process of --type=terminal <img width="521" alt="capture" src="https://user-"
I upgraded to node-pty which may improve the problem, if not I'd guess this is related towinpty is not terminating the processes correctly.
I retested this and it is still happening under Insider today.
terminalProcess stalls on this native call: , meaning this function never returns Not sure why a or native exception isn't happening.
This has the same root cause as
Moving to September as this is a more involved change than I anticipated. More testing in Insiders would be ideal.
any news on this. Do I need to adopt something here ?
No progress, I moved this to September before I knew that I would be out for 2 weeks in September.
It does look like it affects Windows only.
Hmm, I believe that I just came across this while trying to run some tests, and exited with an error code. I was able to reproduce it using this: Everything works fine if the error code is changed to .
Was this never solved?
Code change:
rows }; <del> this._ptyProcess = pty.spawn(shellLaunchConfig.executable, shellLaunchConfig.args, options); </del> <ins> try { this._ptyProcess = pty.spawn(shellLaunchConfig.executable, shellLaunchConfig.args, options); } catch (error) { // The only time this is expected to happen is when the file specified to launch with does not exist. this._exitCode = 2; this._queueProcessExit(); return; } </ins> this._ptyProcess.on('data', (data) => { this._onProcessData.fire(data); if (this._closeTimeout) {

Related discussion:
text: when I last tested this I had the impression that this is still a bug and the terminal hangs (doesn't signal on exit).
Yes, this is still an issue.
Is this in line to be fixed btw?
This still happens btw when I'm doing my PowerShell development.....I have to keep restarting all of VSCode because my debugging sessions won't end properly.
does this sound like something that will be fixed by conpty?
it probably needs a check in node-pty that the file exists before attempting to fire it. It's possible that conpty would fix this but that would only fix it for newer Windows versions when the fix should work when we fallback to winpty.
There's already a check in node-pty before attempting to execute the file. I can't actually reproduce this with a garbage command in my task (ex. ) I do think I'm seeing this when I pass garbage in for the that results in a failure though: 'c:usersalrosdesktop' is not recognized as an internal or external command, operable program or batch file.`
Code change:
} export interface MainThreadWorkspaceShape extends IDisposable { <del> $startFileSearch(includePattern: string | undefined, includeFolder: URI | undefined, excludePatternOrDisregardExcludes: string | false, maxResults: number, token: CancellationToken): Promise<UriComponents[] | undefined>; </del> <ins> $startFileSearch(includePattern: string | undefined, includeFolder: URI | undefined, excludePatternOrDisregardExcludes: string | false | undefined, maxResults: number, token: CancellationToken): Promise<UriComponents[] | undefined>; </ins> $startTextSearch(query: IPatternInfo, options: ITextQueryBuilderOptions, requestId: number, token: CancellationToken): Promise<vscode.TextSearchComplete>; $checkExists(includes: string[], token: CancellationToken): Promise<boolean>; $saveAll(includeUntitled?: boolean): Promise<boolean>;

Related discussion:
text: returns the same results as . The first should have applied, the second should have no exclude settings applied. The parameter in the findFiles API treats differently from . Strict null checking extHostWorkspace broke that:
Code change:
const DEBUG_SELECTED_CONFIG_NAME_KEY = 'debug.selectedconfigname'; const DEBUG_SELECTED_ROOT = 'debug.selectedroot'; <del> const DEBUG_SELECTED_CONFIG = 'debug.selectedconfig'; </del> export class ConfigurationManager implements IConfigurationManager { private debuggers: Debugger[];

Related discussion:
text: VS Code 1.46 start VS Code Stable use this launch config: close "" editor run it Observe: (everything is good) <img width="749" alt="2020-06-1609-34-37" src="https://user-"- shutdown VS Code open same project with VS Code Insiders (or any other editor) modify "" and include argument "1234" between "hello" and "world" shutdown VS Code Insiders launch VS Code Stable again go to debug view and run "echo args" launch config open Observe: <img width="1080" alt="2020-06-1609-39-11" src="https://user-"VS Code runs old launch config which lacks the "1234". Workaround: an edit change of is needed before VS Code will run the correct launch config.
We no longer store the configuration in storage. The only downside is that now when you select a dynamic configuration, reload, we do not preserve the dynamic configuratoin and you have to select it again. For that we would have to store the "origin" as you suggested, but that I will tackle as a seperate issue, thus reopening
I've verified that no stale launch configs are run.
Code change:
export interface ProfileContentHandler { readonly name: string; <ins> readonly description?: string; </ins> saveProfile(name: string, content: string, token: CancellationToken): Thenable<{ readonly id: string; readonly link: Uri } | null>; readProfile(idOrUri: string | Uri, token: CancellationToken): Thenable<string | null>; }

Related discussion:
text: Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.
Code change:
'c:foo/barbaz', 'foo/bar', 'foo/bar', <ins> 'foo/[bar]', 'foo/[bar].baz', 'foo/[bar]/baz', </ins> 'foobar', <ins> 'foo[bar].baz', 'foo[bar]baz', </ins> 'foobar+more', ];

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.71.0-insider OS Version: macOS Big Sur 11.6 Steps to Reproduce: a link in terminal containing "[" or "]" characters (ex. ) to cmd+click the link, observe that it is split on those characters. For example, links to , , , , and . In reality this is one valid path (nextjs uses "[ ]" to identify parameters in URLs) <img width="526" alt="Screen Shot 2022-09-22 at 5 12 00 PM" src="https://user-"
This works for urls: ! Not local paths: !
reported that it does (kind of) work: ! We would need to review all link detectors for this.
This happens with local links because [] are currently excluded chars:
Code change:
await this._revertChanges(textEditor, [...changes.slice(0, index), ...changes.slice(index + 1)]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 0)]; }

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.71.0 (user setup) OS Version: Windows_NT x64 10.0. Git Version: 2.30.2 (Windows) Steps to Reproduce: a new directory a new Git repository a new file and append some text on the first lines this file to the staging the line with text An OS native dialog box error pops up with the title of this issue as text. In the console output for Git: I have had this problem for a long time, 2 years I would say. I thought someone would have reported it but it seems not.
I'm having a similar issue on macOS 12.6 (21G115). If you have deleted lines at the top of a file and click the little arrow to undo the change, the error pops up. Notably, it still completes the undo. <img width="396" alt="image" src="https://user-"
apologies for not getting back to you on this. I used the repro steps above but I was unable to reproduce the problem with the latest VS Code Insiders (1.75) release. Could you please do me a favour and see if you are still able to reproduce the issue? If so, could you please share a recording using so that I can further investigate the issue? Thanks!
Issue is still present in the latest insider release on macOS. !
Code change:
await this._revertChanges(textEditor, [...changes.slice(0, index), ...changes.slice(index + 1)]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 0)]; }

Related discussion:
text: VSCode info: Version: 1.75.0-insider Commit: Date: 2022-12-19T05:35:41.089Z (10 hrs ago) Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes
Code change:
dispose(): void { this.disposables.forEach(d => d.dispose()); } <del> } </del>  No newline at end of file <ins> } </ins>

Related discussion:
text: We have the ability to select which branch to push to in the source control, could we please have a pull from option? To target specific branches. Unless it exists already? I have only recently started using VS Code and i love it!
This is an easy contribution, care to submit a PR? PS: You currently have the ability to select which remote to push to, not which branch.
I'll take on this. Is it correct that branch names are not stored anywhere? I've checked in and cannot find anywhere they could be stored. If there is nothing, I'll just take a user input using showInputBox.
I created a pull request for this: Please take a look when you have the chance.
merge conflict is fixed.
Merging with
Code change:
const shellProcessId = await terminal.processId; if (giveShellTimeToInitialize) { <del> // give a new terminal some time to initialize the shell await new Promise(resolve => setTimeout(resolve, 1000)); </del> <ins> // give a new terminal some time to initialize the shell (most recently, #228191) // - If shell integration is available, use that as a deterministic signal // - Debounce content being written to known when the prompt is available // - Give a longer timeout otherwise const enum Timing { DataDebounce = 500, MaxDelay = 5000, } const ds = new DisposableStore(); await new Promise<void>(resolve => { const scheduler = ds.add(new RunOnceScheduler(resolve, Timing.DataDebounce)); ds.add(this._terminalService.onDidWriteTerminalData(e => { if (e.terminal === terminal) { scheduler.schedule(); } })); ds.add(this._terminalShellIntegrationService.onDidChangeTerminalShellIntegration(e => { if (e.terminal === terminal) { resolve(); } })); ds.add(disposableTimeout(resolve, Timing.MaxDelay)); }); ds.dispose(); </ins> } else { <del> if (terminal.state.isInteractedWith) { </del> <ins> if (terminal.state.isInteractedWith && !terminal.shellIntegration) { </ins> terminal.sendText('u0003'); // Ctrl+C for #106743. Not part of the same command for #107969 await timeout(200); // mirroring https://github.com/microsoft/vscode/blob/c67ccc70ece5f472ec25464d3eeb874cfccee9f1/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L852-L857 }

Related discussion:
text: 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!
Looks like it's solved. Waiting for the official release so Vscode + Cursor will be fixed.
fyi I think cursor is quite a bit behind vscode so I would not expect it to be fixed there soon
Weird, the issue was immediate on both ides a week ago.
Marking as verified due to confirmation.
Code change:
@INotificationService private readonly notificationService: INotificationService, @IEditorResolverService editorResolverService: IEditorResolverService ) { <del> this.run().then(undefined, onUnexpectedError); </del> editorResolverService.registerEditor( `${GettingStartedInput.RESOURCE.scheme}:/**`, {

Related discussion:
text: sure the File Explorer is visible temporary profile window Welcome editor fails to open. cc
Due to:
and I also reproduced this when testing out her walkthrough changes:
Code change:
private _isCommentingEnabled: boolean = true; constructor( <del> @IInstantiationService protected instantiationService: IInstantiationService </del> <ins> @IInstantiationService protected instantiationService: IInstantiationService, @IWorkbenchLayoutService layoutService: IWorkbenchLayoutService </ins> ) { super(); <ins> this._register(layoutService.onDidChangeZenMode(e => { this.enableCommenting(!e); })); </ins> } get isCommentingEnabled(): boolean {

Related discussion:
text: Issue Type: <bBug</bI am not sure if this was something I accidentally enabled, but it looks like it appeared with the latest VSCode version. Hovering over lines now shows a + symbol in the gutter, and it's highly distracting. Is this a bug, or can it be disabled? VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vsc-material-theme33.2.0 vsc-material-theme-icons1.2.2 prettier-vscode9.5.0 copilot1.19.5865 gc-excelviewer4.2.54 vsliveshare1.0.5561 material-theme3.13.25 (5 theme extensions excluded) </details<!-- generated by issue reporter --
https://user-
The "+" on line hover indicates that you can leave an extension comment on that line. We used to only show the "+" when you hovered over the gutter itself, but now we show it over the whole line so that it's easier to find. This means that you have an extension installed that let's you leave comments in files. The extension might have a way for you to disable this. I would like to add a feature to VS Code that just disables all commenting. Assigning to June to work on this.
great to know, thank you. i'll see if I can figure out what the extension is and will disable it in the meantime. it's very distracting - can you consider an option that preserves the old symbol behavior where it is only displayed when hovering in the gutter? comments are useful but there is now too much distracting movement on screen. it also shows in Zen mode which I believe is counter productive.
Good point, this should be disabled in Zen mode.
Bit more thoughts on this: Maybe a setting wouldn't be the right fit for this, since a user might forget that it set it and forget about it... or worse, it could be set at workspace level and the user never even knew it was set. Maybe runtime UI state would work best since it isn't as sticky.
Code change:
private _isCommentingEnabled: boolean = true; constructor( <del> @IInstantiationService protected instantiationService: IInstantiationService </del> <ins> @IInstantiationService protected instantiationService: IInstantiationService, @IWorkbenchLayoutService layoutService: IWorkbenchLayoutService </ins> ) { super(); <ins> this._register(layoutService.onDidChangeZenMode(e => { this.enableCommenting(!e); })); </ins> } get isCommentingEnabled(): boolean {

Related discussion:
text: Additionally, it would be great if there is some indication that comments are indeed hidden as opposed to the current file not having any comments at all. What do you think?
Having some indication that there are comments, they're just hidden, makes sense. We should do this. We can start with some runtime UI state and add a setting later if there's a desire for it.
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "dc3ce65dd5fd872db86e5308ae005a898142435a" </del> <ins> "commitHash": "67b2739f44ce98aad493170fecc696f76dc12de1" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "25.8.1" </del> <ins> "version": "25.8.2" </ins> }, { "component": {

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. --<!-- 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. --Something has changed in the latest Insiders so our CI started to fail with errors (any branch but here is an ): Do you have any idea what might cause it so we can make changes on our side? Might it be something with your dependencies?
Runtime has no changes with insiders, this seems like a regression from the recent http proxy changes based on in upstream. Passing onto From a quick look the extension relies on package which makes network connection. it would be great if you can reduce the test case to a minimal extension sample for us to debug this issue further. Thanks!
Unfortunately, we haven't been able to isolate the issue for a minimal extension sample so far. To reproduce the problem, you can follow these steps: the and install the extension. the following commands in the terminal: When running all tests, you may observe multiple failures with the . However, when running the failed tests separately, they randomly may or may not fail again, which makes it hard to identify the cause of the issue. It is possible that your proxy patches might be the right place to look for further investigation.
Maybe a related discussion:
Found it. The place in our code that fails with the latest Insiders is . I created a so you can try it, but here is the code snippet for a quick look:
Thanks for putting together this test! My investigation so far: is called with resulting in the reported error when it calls here: The check at would prevent from being called when , but that is only with in 19.0.0.