jiebi/CodeConvo huggingface dataset:
Code 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?: No <!-- 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. --Version: 1.91.1 Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a TreeView with an TreeItem the TreeItem's iconPath to the extension. The TreeItem's icon will still be yellow same as in debugging. After inspecting developer tools, this is likely due to how the icon debug-stackframe's color rule is set to !important. The ThemeColor fails to overwrite it due to low specificity. This may not only happen with the icon "debug-stackframe" and is affecting customisations of treeitems. Why is some icons' color rules given the !important flag et al? There might not be any easy fix due to this flag's present. I hope the team could look into it, and if possible fix this selector specificity issue (if it won't break vscode, somehow).
Edit: This not only occurs on special icons like debug-stackframe, but also on very ordinary ones like circle-filled. style attribute { color: rgb(204, 204, 204); } .monaco-workbench .codicon { } Adding !important to the color flag of .monaco-workbench .codicon will fix the issue though.. The problem is worse :C
I think the best solution would be to get rid of that . it's coming from here. Can it be removed? The css you shared is correct. The rbg value is the one you set in your ThemeIcon. !
Yea, we should scope these rules better (and also move them to css now that we have variables there)
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

Related discussion:
text: // align from the bottom so that it lines up with instruction when source code is present. container.style.alignSelf = 'flex-end'; <del> const icon = append(container, $('.disassembly-view')); icon.classList.add('codicon'); </del> <ins> const icon = append(container, $('.codicon')); </ins> icon.style.display = 'flex'; icon.style.alignItems = 'center'; icon.style.justifyContent = 'center';
Code change:
As reported by open notebook open nb from timeline close diff close notebook then I got Can repro from stable

Related discussion:
text: } override dispose() { <ins> // The editor isn't disposed yet, it can be re-used. // However the model can be disposed before the editor & that causes issues. if (this._editor) { this._editor.setModel(null); } </ins> if (this._editor && this._editorViewStateChanged) { this.cell.saveSpirceEditorViewState(this._editor.saveViewState()); }
Code change:
<img width="1072" alt="image" src=""<img width="838" alt="image" src=""

Related discussion:
text: return $('tr', undefined, ...row.map(rowData => { if (typeof rowData === 'string') { <del> return $('td', undefined, rowData); </del> <ins> return $('td', undefined, $('p', undefined, rowData)); </ins> } const data = Array.isArray(rowData) ? rowData : [rowData]; return $('td', undefined, ...data.map(item => {
Code 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/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

Related discussion:
text: alias: { './node/authServer': path.resolve(__dirname, 'src/browser/authServer'), './node/buffer': path.resolve(__dirname, 'src/browser/buffer'), <ins> './node/fetch': path.resolve(__dirname, 'src/browser/fetch'), </ins> './node/authProvider': path.resolve(__dirname, 'src/browser/authProvider'), } }
Code 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/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

Related discussion:
text: import { BetterTokenStorage, IDidChangeInOtherWindowEvent } from './betterSecretStorage'; import { LoopbackAuthServer } from './node/authServer'; import { base64Decode } from './node/buffer'; <ins> import fetch from './node/fetch'; </ins> import { UriEventHandler } from './UriEventHandler'; import TelemetryReporter from '@vscode/extension-telemetry'; import { Environment } from '@azure/ms-rest-azure-env';
Code 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/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

Related discussion:
text: let result; let errorMessage: string | undefined; try { <del> result = await fetch(endpoint, { </del> <ins> result = await fetch(endpoint.toString(), { </ins> method: 'POST', headers: { <del> 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': postData.length.toString() </del> <ins> 'Content-Type': 'application/x-www-form-urlencoded' </ins> }, body: postData });
Code 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/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

Related discussion:
text: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ export default fetch; </ins>
Code 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/No No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

Related discussion:
text: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ let _fetch: typeof fetch; try { _fetch = require('electron').net.fetch; } catch { _fetch = fetch; } export default _fetch; </ins>
Code change:
Testing Repro steps: some changes to a cell, in my case I a cell with some content the changes some lines from the cell that was in step 1, and save. diff view launched from "changes" SCM view should diff between staged and working.
Now the diff view for the changes in the 'Staged Changes' group is the same as the diff view for the unstaged changes
I am seeing it as I would expect. This is diff launched from staged (where the cell was ) ! This is diff launched on unstaged: !
Works for me too, can you share the text file contents in the 3 cases Commited ipynb Staged ipynb & finally changed ipynb
Original steps LGTM
Original file: ! Modification 1: ! Modification 2: ! Observe that the diffs for the Staged and Working Changes regions below are identical !

Related discussion:
text: this._versionId = this._textModel.getVersionId(); this._alternativeId = this._textModel.getAlternativeVersionId(); } <ins> this._textBufferHash = null; </ins> this._onDidChangeContent.fire('content'); }));
Code change:
Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

Related discussion:
text: import { $, append } from 'vs/base/browser/dom'; import { IHoverOptions, IManagedHover, IManagedHoverTooltipMarkdownString } from 'vs/base/browser/ui/hover/hover'; import { IHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegate'; <del> import { createInstantHoverDelegate, getDefaultHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegateFactory'; </del> <ins> import { getDefaultHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegateFactory'; </ins> import { IconLabel } from 'vs/base/browser/ui/iconLabel/iconLabel'; import { IIdentityProvider, IKeyboardNavigationLabelProvider, IListVirtualDelegate } from 'vs/base/browser/ui/list/list'; import { LabelFuzzyScore } from 'vs/base/browser/ui/tree/abstractTree';
Code change:
Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

Related discussion:
text: templateData.labelContainer.textContent = ''; if (historyItem.labels) { <del> const instantHoverDelegate = createInstantHoverDelegate(); templateData.elementDisposables.add(instantHoverDelegate); </del> // Get lits of labels to render (current, remote, base) const labels = this.getLabels(node.element.repository);
Code change:
Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

Related discussion:
text: if (label.icon && ThemeIcon.isThemeIcon(label.icon) && labels.includes(label.title)) { const icon = append(templateData.labelContainer, $('div.label')); icon.classList.add(...ThemeIcon.asClassNameArray(label.icon)); <del> const hover = this.hoverService.setupManagedHover(instantHoverDelegate, icon, label.title); templateData.elementDisposables.add(hover); </del> } } }
Code 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. --Version: 1.93.0-insider Commit: Date: 2024-08-29T05:04:03.909Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: a few editor groups in seemingly any split configuration one for text input or otherwise run to type: no result, as no editor has focus any more. This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.
In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
<!-- 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

Related discussion:
text: const editorGroupService = accessor.get(IEditorGroupsService); const newOrientation = (editorGroupService.orientation === GroupOrientation.VERTICAL) ? GroupOrientation.HORIZONTAL : GroupOrientation.VERTICAL; editorGroupService.setGroupOrientation(newOrientation); <ins> editorGroupService.activeGroup.focus(); </ins> } });