jiebi/CodeConvo huggingface dataset:
Code change:
"resolved": "https://registry.npmjs.org/tas-client-umd/-/tas-client-umd-0.2.0.tgz", "integrity": "sha512-oezN7mJVm5qZDVEby7OzxCLKUpUN5of0rY4dvOWaDF2JZBlGpd3BXceFN8B53qlTaIkVSzP65aAMT0Vc+/N25Q==" }, <ins> "node_modules/tslib": { "version": "2.7.0", "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.7.0.tgz", "integrity": "sha512-gLXCKdN1/j47AiHiOkJN69hJmcbGTHI0ImLmbYLHykhgeN0jVGola9yVjFgzCUklsZQMW55o+dW7IXv3RCXDzA==", "peer": true }, </ins> "node_modules/vscode-oniguruma": { "version": "1.7.0", "resolved": "https://registry.npmjs.org/vscode-oniguruma/-/vscode-oniguruma-1.7.0.tgz",

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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.
Code change:
"resolved": "https://registry.npmjs.org/tas-client-umd/-/tas-client-umd-0.2.0.tgz", "integrity": "sha512-oezN7mJVm5qZDVEby7OzxCLKUpUN5of0rY4dvOWaDF2JZBlGpd3BXceFN8B53qlTaIkVSzP65aAMT0Vc+/N25Q==" }, <ins> "node_modules/tslib": { "version": "2.7.0", "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.7.0.tgz", "integrity": "sha512-gLXCKdN1/j47AiHiOkJN69hJmcbGTHI0ImLmbYLHykhgeN0jVGola9yVjFgzCUklsZQMW55o+dW7IXv3RCXDzA==", "peer": true }, </ins> "node_modules/vscode-oniguruma": { "version": "1.7.0", "resolved": "https://registry.npmjs.org/vscode-oniguruma/-/vscode-oniguruma-1.7.0.tgz",

Related discussion:
text: I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.
Code change:
"resolved": "https://registry.npmjs.org/tas-client-umd/-/tas-client-umd-0.2.0.tgz", "integrity": "sha512-oezN7mJVm5qZDVEby7OzxCLKUpUN5of0rY4dvOWaDF2JZBlGpd3BXceFN8B53qlTaIkVSzP65aAMT0Vc+/N25Q==" }, <ins> "node_modules/tslib": { "version": "2.7.0", "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.7.0.tgz", "integrity": "sha512-gLXCKdN1/j47AiHiOkJN69hJmcbGTHI0ImLmbYLHykhgeN0jVGola9yVjFgzCUklsZQMW55o+dW7IXv3RCXDzA==", "peer": true }, </ins> "node_modules/vscode-oniguruma": { "version": "1.7.0", "resolved": "https://registry.npmjs.org/vscode-oniguruma/-/vscode-oniguruma-1.7.0.tgz",

Related discussion:
text: 3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it
Code change:
// Show all results only when filtering begins, this is done so the quick pick will show up // ASAP with only the viewport entries. let accepted = false; <del> const disposables = new DisposableStore(); </del> if (!usingAllLinks) { disposables.add(Event.once(pick.onDidChangeValue)(async () => { const allLinks = await links.all;

Related discussion:
text: Quick pick and events are disposables: is a listeners are : , , , , , A few instances of pickers or events not being disposed or registered as disposable: [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] //cc
Thanks for catching these just taught me that there's a better way to use the quick pick API - with and that will avoid this
Interesting, curious to see how that change looks like, I have a lot more places:
Code change:
// Install the Extension and reload the window to handle. const result = await this.dialogService.confirm({ <del> message: localize('installAndHandle', "Extension '{0}' is not installed. Would you like to install the extension and reload the window to open this URL?", galleryExtension.displayName || galleryExtension.name), </del> <ins> message: localize('installAndHandle', "Extension '{0}' is not installed. Would you like to install the extension and open this URL?", galleryExtension.displayName || galleryExtension.name), </ins> detail: `${galleryExtension.displayName || galleryExtension.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, <del> primaryButton: localize('install', "&&Install"), </del> <ins> primaryButton: localize('install and open', "&&Install and Open"), </ins> type: 'question' });

Related discussion:
text: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing
Code change:
MergeEditorSerializer ); <ins> registerAction2(OpenResultResource); </ins> registerAction2(SetMixedLayout); registerAction2(SetColumnLayout); registerAction2(OpenMergeEditor);

Related discussion:
text: Same as when opening a diff editor, a merge editor should offer a way to open the regular file (not in 3 way merge mode). Same as diff editor it could use an action in the editor title area !
Let's move this to July
To verify: open a merge editor verify its title bar has a command to open the result file
I wonder if "Open Changes" button should go back to the merge editor then? !
Code change:
commandLineMatcher: GitPushCommandLineRegex, // Example output: // ... <del> // 9:  remote: // 8:  remote: Create a pull request for 'my_branch' on GitHub by visiting: // 7:  remote:      https://github.com/microsoft/vscode/pull/new/my_branch // 6:  remote: // 5:  remote: GitHub found x vulnerabilities on microsoft/vscode's default branch (...). To find out more, visit: // 4:  remote:      https://github.com/microsoft/vscode/security/dependabot // 3:  remote: // 2:  To https://github.com/microsoft/vscode // 1:  * [new branch]              my_branch -> my_branch // 0:  Branch 'my_branch' set up to track remote branch 'my_branch' from 'origin'. </del> <ins> // 10: remote: // 9:  remote: Create a pull request for 'my_branch' on GitHub by visiting: // 8:  remote:      https://github.com/microsoft/vscode/pull/new/my_branch // 7:  remote: // 6:  remote: GitHub found x vulnerabilities on microsoft/vscode's default branch (...). To find out more, visit: // 5:  remote:      https://github.com/microsoft/vscode/security/dependabot // 4:  remote: // 3:  To https://github.com/microsoft/vscode // 2:  * [new branch]              my_branch -> my_branch // 1:  Branch 'my_branch' set up to track remote branch 'my_branch' from 'origin'. // 0: </ins> outputMatcher: { lineMatcher: GitCreatePrOutputRegex, anchor: 'bottom', <del> offset: 3, length: 6 </del> <ins> offset: 4, // ~6 should only be needed here for security alerts, but the git provider can customize // the text, so use 12 to be safe. length: 12 </ins> }, commandExitResult: 'success', getQuickFixes: (matchResult: ITerminalCommandMatchResult) => {

Related discussion:
text: the match always happens, the lightbulb doesn't show up though until I resize the terminal
this happens when the have not yet been resolved by the time occurs ! !
I think we should be calling at the end of
have seen the create PR not show up 3 times today. resizing doesn't cause it to show up, which means our match range is wrong/ there isn't a match
this says unreleased, but was merged before the current version of insider's (5 hours ago) was released. create with PR still failing !
insider's is based on the release branch, so I was confused
<!-- UNABLETOLOCATECOMMITMESSAGE issue --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
Code change:
import { getTitleBarStyle } from 'vs/platform/window/common/window'; import { mainWindow } from 'vs/base/browser/window'; import { isFullscreen, onDidChangeFullscreen } from 'vs/base/browser/browser'; <ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </ins> export class WorkbenchContextKeysHandler extends Disposable { private inputFocusedContext: IContextKey<boolean>; private dirtyWorkingCopiesContext: IContextKey<boolean>; <ins> private activeEditorGroupEmpty: IContextKey<boolean>; private activeEditorGroupIndex: IContextKey<number>; private activeEditorGroupLast: IContextKey<boolean>; private activeEditorGroupLocked: IContextKey<boolean>; private multipleEditorGroupsContext: IContextKey<boolean>; private editorsVisibleContext: IContextKey<boolean>; </ins> private splitEditorsVerticallyContext: IContextKey<boolean>; private workbenchStateContext: IContextKey<string>;

Related discussion:
text: Reproduced on OSS, Mac Steps to Reproduce: Code OSS a file cmd+w Closes the window Bisect points to this commit -
I can reproduce and this is likely context keys not being set properly because conditionally closes the window if no active editor. !
There are context keys that are now loose, for example
Follow up work
Code change:
"command.deleteBranch": "Delete Branch...", "command.pull": "Pull", "command.pullRebase": "Pull (Rebase)", <ins> "command.pullFrom": "Pull (From Remote)", </ins> "command.push": "Push", "command.pushTo": "Push to...", "command.sync": "Sync",

Related discussion:
text: In VS Code we able to push git repos to different places with "git push to" and choosing the remote server to push. I'll be nice if we can be able to choose from the repo to pull files, and manage the default remote, today the first remote repo is the default isn't possible to change that via VS Code
Thanks for all your contributions. You all created a PR to solve the same issue; all in a surprisingly similar way. I wanted to keep the record of all your work so I did an octopus merge with git, thus keeping your names in history. Thanks once again!
Code change:
"vscode-oniguruma": "1.7.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "xterm": "5.2.0-beta.35", "xterm-addon-canvas": "0.4.0-beta.9", </del> <ins> "xterm": "5.2.0-beta.40", "xterm-addon-canvas": "0.4.0-beta.11", </ins> "xterm-addon-search": "0.11.0", "xterm-addon-serialize": "0.9.0", "xterm-addon-unicode11": "0.5.0", <del> "xterm-addon-webgl": "0.15.0-beta.8", "xterm-headless": "5.2.0-beta.35", </del> <ins> "xterm-addon-webgl": "0.15.0-beta.10", "xterm-headless": "5.2.0-beta.40", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: OS Version: Steps to Reproduce: a terminal window within vscode and run this command: vscode hangs indefinitely, using 100% CPU on one core. It would be nice if that didn't happen.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I'm using web version (Vscode Server) and this code snippet cause the entirely browser tab to crash: ! Wanted to provide profiling info but profiler hanged too
I can reproduce
Nice find
Upstream:
Code change:
this._accessibleViewCurrentProviderId.set(provider.verbositySettingKey.replaceAll('accessibility.verbosity.', '')); } const value = this._configurationService.getValue(provider.verbositySettingKey); <del> const readMoreLink = provider.options.readMoreUrl ? localize("openDoc", "nnPress H now to open a browser window with more information related to accessibility.nn") : ''; </del> <ins> const readMoreLink = provider.options.readMoreUrl ? localize("openDoc", "nnOpen a browser window with more information related to accessibility (H).") : ''; </ins> let disableHelpHint = ''; if (provider.options.type === AccessibleViewType.Help && !!value) { disableHelpHint = this._getDisableVerbosityHint(provider.verbositySettingKey);

Related discussion:
text: As a result of the discussion in , we should format each command, description, and keybinding more consistently and limit redundancy.
/closedWith though still need to do the same for the chat help dialogs
Code change:
background-color: var(--vscode-chat-list-background); } <ins> .interactive-item-container.interactive-request .header .monaco-toolbar { /* Take the partially-transparent background color override for request rows */ background-color: inherit; } </ins> .interactive-item-container .header .monaco-toolbar .checked.action-label, .interactive-item-container .header .monaco-toolbar .checked.action-label:hover { color: var(--vscode-inputOption-activeForeground) !important;

Related discussion:
text: Testing ! !
doesn't reproduce in the panel chat
I somehow suffer from this change which explicitly targets some monaco tokens...
This isn't nice but there's actually no other way to override the foreground color of an editor- because typically you have syntax highlighting. We do this for all the other "input box"-style editors. I think I opened a feature request when I did this. We should align this rule with your rule for coloring the decoration so that it can override it properly.
labeling so it gets verified
Thanks
in the latest insider's, still seeing this ! !
There is two separate issues with different steps. There is a difference between rendering of slash command and normal prompt text. the only useful/visible information in the original issue description is slash commands (please use words and not images to describe issues!). For verification you have not used slash commands but normal prompt text which is a different case. Please file a separate issue, use words/steps and don't rely on screen captures with just white on white text
Steps to reproduce/verify use HC light and dark theme open inline chat and type a slash command, e.d make sure the command is readable when selecting its text
Code change:
resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0.tgz#41c0d96acc1e3bb6c6596eee64e163b6bca74be7" integrity sha512-Jm4/g4QiTxiKiTbYICQgC791ubhIZyoIwxAIgOW8z8HWFNY+lwk+dwaKEaEeGBfM48Vk8fklsUW9u/PlenYEBg== <del> xterm-addon-webgl@0.15.0-beta.8: version "0.15.0-beta.8" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.8.tgz#2005198582f6f1f4a9b2612b9354c0bcc9f148d8" integrity sha512-HjTr9bi3FvdOIPaaIpih6qdHX2z+H7sQPluLj5KzwCqRiEVUVRi19dl8SdHjf6dCmN3GahMhjV7D+zxHi2pLTw== </del> <ins> xterm-addon-webgl@0.15.0-beta.10: version "0.15.0-beta.10" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.10.tgz#39ebbfb1b89c6773a2d8cb8e1d2f3ef1f08b28f9" integrity sha512-JVv4t5q6QGWyLiEAcAk9H2B83hFlIalzEwWu1VVYso0MJyZAlZ0NP5Za03iSKxYi7RQIA5bOe8r7W24esQDjLg== </ins> <del> xterm-headless@5.2.0-beta.35: version "5.2.0-beta.35" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.35.tgz#8c3d4d06747e27a5bc4f0bf914479820a5b8f529" integrity sha512-tq/zKnXEsVXGlhXHGNqPO47x9Fvew2avZ0wfMI1G80AEYrjxGY/3Quxwe9/C5ngIuPwk2CMbgDZwHhSFvyOrMA== </del> <ins> xterm-headless@5.2.0-beta.40: version "5.2.0-beta.40" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.40.tgz#6edba318d23ed350c8ec6279e6f61f40bde9b163" integrity sha512-6CHgR64POfa24CTILcq/HHg1im1u1HjJZSHWjlopP18KiS8Rq8dzCurZDsu38atxDK9dyjV8SRw2AB4ijcxZsQ== </ins> <del> xterm@5.2.0-beta.35: version "5.2.0-beta.35" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.35.tgz#4a0c0aa81c89c42167c22d023648cced44fa3c25" integrity sha512-6x6i61lucRrLWRKFeMO/ZOx5anvYR6FHpReLO2g0y1bp5zYWyZFzM6DepMV50729gubzxSLB8mvbmb9EpeIugQ== </del> <ins> xterm@5.2.0-beta.40: version "5.2.0-beta.40" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.40.tgz#c73d5576425dcd4fa6b48ce58b4224a7b5b9dbdf" integrity sha512-7/Db3KPceM0VX4/YAKL+/ArvEHlGBwE3kt1oN9QP5TLaJ6r2ThMS7z7QwG8g2gy60GFnvjfvpcTv6Ewyste4zg== </ins> yallist@^4.0.0: version "4.0.0"

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: OS Version: Steps to Reproduce: a terminal window within vscode and run this command: vscode hangs indefinitely, using 100% CPU on one core. It would be nice if that didn't happen.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I'm using web version (Vscode Server) and this code snippet cause the entirely browser tab to crash: ! Wanted to provide profiling info but profiler hanged too
I can reproduce
Nice find
Upstream:
Code change:
const editor = await vscode.window.showNotebookDocument(notebook); const notebookChangeEvent = asPromise<vscode.NotebookDocumentChangeEvent>(vscode.workspace.onDidChangeNotebookDocument); <del> const version = editor.document.version; await editor.edit(editBuilder => { editBuilder.replaceCells(1, 0, [{ kind: vscode.NotebookCellKind.Code, languageId: 'javascript', value: 'test 2', outputs: [], metadata: undefined }]); editBuilder.replaceCellMetadata(0, { inputCollapsed: false }); }); </del> <ins> const version = editor.notebook.version; const edit = new vscode.WorkspaceEdit(); const cellEdit = vscode.NotebookEdit.replaceCells(new vscode.NotebookRange(1, 0), [{ kind: vscode.NotebookCellKind.Code, languageId: 'javascript', value: 'test 2', outputs: [], metadata: undefined }]); const metdataEdit = vscode.NotebookEdit.updateNotebookMetadata({ ...notebook.metadata, custom: { ...(notebook.metadata.custom || {}), extraNotebookMetadata: true } }); edit.set(notebook.uri, [cellEdit, metdataEdit]); await vscode.workspace.applyEdit(edit); </ins> await notebookChangeEvent; <del> assert.strictEqual(version + 1, editor.document.version); </del> <ins> const notebookChangeEvent2 = asPromise<vscode.NotebookDocumentChangeEvent>(vscode.workspace.onDidChangeNotebookDocument); const edit2 = new vscode.WorkspaceEdit(); const cellMetadataEdit = vscode.NotebookEdit.updateCellMetadata(0, { extraCellMetadata: true }); edit2.set(notebook.uri, [cellMetadataEdit]); await vscode.workspace.applyEdit(edit2); await notebookChangeEvent2; assert.strictEqual(version + 2, editor.notebook.version); const cell = editor.notebook.cellAt(0); assert.ok(editor.notebook.metadata.custom.extraNotebookMetadata, `Test metadata not found`); assert.ok(cell.metadata.extraCellMetadata, `Test cell metdata not found`); </ins> }); test('edit API batch edits undo/redo', async function () {

Related discussion:
text: create a notebook and save it. Run a cell with a kernel. Change the kernel and run another cell reopen the notebook as plain text and note the kernel spec in the metadata. metadata should specify the kernel that was most recently used, but it specifies the original. Seems to repro with both local and remote kernels
impacts microsoft/vscode-jupyter since we're not getting the correct suggestion
I think this is a regression. please could you verify this works as expected in stable.
yes, the kernelspec updates in stable as expected
This is actually a bug in the new metadata API. Transferring to vscode core.
This should've been assigned to since we are adamant in verifying each issue that gets shipped in a recovery release individually. I found this out by looking into . Please find someone to verify this issue in the latest release candidate build.
Oh my bad... this was released already in ... My mistake.
But there's still a recommendation: this should've been assigned to all along so people verify the issue was fixed. Can you find someone to verify and mark it as ?
I had actually verified back when it was fixed, just didn't add the label since it wasn't marked verification needed. I'll do that now tho
Thanks!