jiebi/CodeConvo huggingface dataset:
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { CellKind } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { withTestNotebook } from 'vs/workbench/contrib/notebook/test/browser/testNotebookEditor'; import { ensureNoDisposablesAreLeakedInTestSuite } from 'vs/base/test/common/utils'; import { Event } from 'vs/base/common/event'; suite('CellDecorations', () => { ensureNoDisposablesAreLeakedInTestSuite(); test('Add and remove a cell decoration', async function () { await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}], ], async (editor, viewModel) => { const cell = viewModel.cellAt(0); assert.ok(cell); let added = false; Event.once(cell.onCellDecorationsChanged)(e => added = !!e.added.find(decoration => decoration.className === 'style1')); const decorationIds = cell.deltaCellDecorations([], [{ className: 'style1' }]); assert.ok(cell.getCellDecorations().find(dec => dec.className === 'style1')); let removed = false; Event.once(cell.onCellDecorationsChanged)(e => removed = !!e.removed.find(decoration => decoration.className === 'style1')); cell.deltaCellDecorations(decorationIds, []); assert.ok(!cell.getCellDecorations().find(dec => dec.className === 'style1')); assert.ok(added); assert.ok(removed); }); }); test('Removing one cell decoration should not remove all', async function () { await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}], ], async (editor, viewModel) => { const cell = viewModel.cellAt(0); assert.ok(cell); const decorationIds = cell.deltaCellDecorations([], [{ className: 'style1', outputClassName: 'style1' }]); cell.deltaCellDecorations([], [{ className: 'style1' }]); let styleRemoved = false; let outputStyleRemoved = false; Event.once(cell.onCellDecorationsChanged)(e => { styleRemoved = !!e.removed.find(decoration => decoration.className === 'style1'); outputStyleRemoved = !!e.removed.find(decoration => decoration.outputClassName === 'style1'); }); // remove the first style added, which should only remove the output class cell.deltaCellDecorations(decorationIds, []); assert.ok(!cell.getCellDecorations().find(dec => dec.outputClassName === 'style1')); assert.ok(cell.getCellDecorations().find(dec => dec.className === 'style1')); assert.ok(!styleRemoved); assert.ok(outputStyleRemoved); }); }); }); </ins>

Related discussion:
text: Steps to Reproduce: a notebook with a markdown cell that has multiple headers e.g. the preview for the markdown cell - shift+enter symbols quickpick ctrl+shift+o and arrow down through the symbols list :bug: cell decoration appears for the first item but then is removed for the second
Code change:
// The widget's position is undefined until the widget has been displayed, so rely on the glyph position instead const existingCommentsAtLine = this._commentWidgets.filter(widget => widget.getGlyphPosition() === commentRange.endLineNumber); if (existingCommentsAtLine.length) { <del> existingCommentsAtLine.forEach(widget => widget.toggleExpand()); </del> <ins> const allExpanded = existingCommentsAtLine.every(widget => widget.expanded); existingCommentsAtLine.forEach(allExpanded ? widget => widget.collapse() : widget => widget.expand()); </ins> this.processNextThreadToAdd(); return; } else {

Related discussion:
text: VSCode Version: 1.36.0 OS Version: Windows 10 Repro steps: Live Share extension 1.0.488, start a collaboration session two comment threads on a single line. Comment on a line, 3 for example Comment on a second line, 4 for example Delete line 3 Now there are two comment threads on line 3 (the line that moved up from 4) /Collapse the comments with the marker Collapsing/opening such comments might need a rework. Currently I can collapse each individually, and if all are collapsed (or all open), the box on the gray line opens (or closes) all threads. However, if only some of the threads are collapsed, the gray box toggles between the set of open threads and the threads which were collapsed. It never collapses all threads to return to code, and requires each remaining thread to be collapsed individually. Originally reported in Live Share issue
As I was just about to file the same thing, here is the screencast I created for illustration: !
I agree the current behavior is a bit confusing. Clicking in the gutter is a common way to collapse open comments. However, the workflow fails when multiple comments are on the same line. This forces the user to think and use the alternative workflow (top-right icon). Suggested behavior: if at least one comment is expanded, collapse all comments on the line otherwise, expand all the comments The condition could also be reversed (expand if the line has both expanded and collapsed comments).
Since we just came across the relevant code again in another context: clicks on the gutter icon currently toggle the collapsible states for all threads on that line independently here: already exists as a private property, if there was a public getter for it, behavior like the one suggested by above could probably be implemented very locally in the location I linked to above. let us know if that sounds reasonable and we can make a PR.
yes, this sounds reasonable to me. l would accept a PR!
I opened .
Code change:
this.renderTree(undefined, forceRefresh); } else { this.settingsTreeModel = this.instantiationService.createInstance(SettingsTreeModel, this.viewState, this.workspaceTrustManagementService.isWorkspaceTrusted()); <del> this.settingsTreeModel.update(resolvedSettingsRoot); this.tocTreeModel.settingsTreeRoot = this.settingsTreeModel.root as SettingsTreeGroupElement; </del> <ins> this.refreshModels(resolvedSettingsRoot); </ins> // Don't restore the cached state if we already have a query value from calling _setOptions(). const cachedState = !this.viewState.query ? this.restoreCachedState() : undefined;

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?: Unknown- repro uses a virtual workspace <!-- 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: OS Version: Version: 1.80.0 Commit: Date: 2023-07-04T15:06:02.407Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Steps to Reproduce: a Github repository using "GitHub Repositories" extension, eg microsoft/vscode "Settings (JSON)" and add all tabs except Getting Started Extensions panel, search for " typescript" the Typescript and JavaScript Language Features extension and Reload Window "Settings (UI)" and search for typescript- no settings appear. Close "Settings (UI)" Extensions panel, search for " typescript" and re-enable the extension. Note, the extension activates immediately, the panel doesn't recommend Reload Window. "Settings (UI)" and search for typescript- Actual: no settings appear. Expected: settings appear
Code change:
private setSourceOptions(): void { const sourceSelect = this.getElementById('issue-source')! as HTMLSelectElement; <del> const { issueType, fileOnExtension } = this.issueReporterModel.getData(); </del> <ins> const { issueType, fileOnExtension, selectedExtension } = this.issueReporterModel.getData(); </ins> let selected = sourceSelect.selectedIndex; <del> if (selected === -1 && fileOnExtension !== undefined) { selected = fileOnExtension ? 2 : 1; </del> <ins> if (selected === -1) { if (fileOnExtension !== undefined) { selected = fileOnExtension ? 2 : 1; } else if (selectedExtension?.isBuiltin) { selected = 1; } </ins> } sourceSelect.innerHTML = '';

Related discussion:
text: Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Code change:
depsStr = line.substring(shlibsDependsPrefix.length); } } <del> const requires = new Set(depsStr.split(', ').sort()); </del> <ins> // Refs https://chromium-review.googlesource.com/c/chromium/src/+/3572926 // Chromium depends on libgcc_s, is from the package libgcc1.  However, in // Bullseye, the package was renamed to libgcc-s1.  To avoid adding a dep // on the newer package, this hack skips the dep.  This is safe because // libgcc-s1 is a dependency of libc6.  This hack can be removed once // support for Debian Buster and Ubuntu Bionic are dropped. const filteredDeps = depsStr.split(', ').filter(dependency => { return !dependency.startsWith('libgcc-s1'); }).sort(); const requires = new Set(filteredDeps); </ins> return requires; }

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: Insiders 1.71 OS Version: Ubuntu 18.04 amd64 Steps to Reproduce: to install latest code-insiders packages from MS repository () The issue is that with the dependency on Debian derivatives changed to which only exists on newer releases (20.04 and later I think). I realise that support for Ubuntu-Ancient is low on the priority list, but I am sadly stuck with it, and would appreciate if there was a workaround. Installing newer libgcc releases as suggested in some places easily leads to a very broken system.
This is a side effect of now using bullseye sysroot, we should apply the following change https://chromium- to our debian calculate package deps.
Code change:
import { EditSessionsFileSystemProvider } from 'vs/workbench/contrib/editSessions/browser/editSessionsFileSystemProvider'; import { isNative } from 'vs/base/common/platform'; import { WorkspaceFolderCountContext } from 'vs/workbench/common/contextkeys'; <ins> import { ThemeIcon } from 'vs/platform/theme/common/themeService'; </ins> registerSingleton(IEditSessionsLogService, EditSessionsLogService); registerSingleton(IEditSessionsWorkbenchService, EditSessionsWorkbenchService);

Related discussion:
text: ! should align more with <img width="672" alt="image" src="https://user-"
Code change:
wait_for_async_execs <del> exec "$@" "--no-sandbox" </del> <ins> exec "$@" </ins>

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/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. --- VS Code Version: 1.90.1 x64 OS Version: Ubuntu 24.04 (Updates 14 Jun 2024) I get the error on a fresh installation of Ubuntu 24.04 and VSCode 1.90.1 Everything works fine with VSCode version . Steps to Reproduce: latest version of Ubuntu 24.04. command. command.
In my case the issue occurred when doing , also on Ubuntu (20.04) and also on vscode 1.90.1 Here is a temp workaround to revert to vscode 1.89.1, if that's useful to anyone:
Hi Having same issue on remote VM Ubuntu 20.04 Install errors with Solved by using the flag
Code change:
wait_for_async_execs <del> exec "$@" "--no-sandbox" </del> <ins> exec "$@" </ins>

Related discussion:
text: This is a continuation of to implement a proper fix in the runtime or application as necessary. Known data points: SIGTRAP when gpu tried to access resource bundle to load a label for assigning display name when computing vsync interval using the internal implementation rather than the gl extension. Also name from resource bundle is only requested for builtin-displays and not virtual ;l=449-456 Using gpu codepath from main process serves as a workaround. Debian package on the same system didn't trigger the crash codepath, very likely a different gl backend was used. Next steps: 1) Compare gl initialization trace between snap 1.89 and 1.90, using the following categories 2) Compare gl initialization trace between debian 1.90 and snap 1.90 3) Confirm if resource bundle access from gpu process is necessary moving forward.
This turned out to be a regression from https://chromium- which causes the gpu process when using the software display compositor to reach into the resource bundle. Before the CL, gpu process will not call into only the main process did.
is there something to verify here?
This is related to the candidate issue and I was just using it to track fixes. Nothing particular to verify for this particular issue, maybe confirm the checksums for both branches are same vs
Code change:
StartupNotify=false StartupWMClass=@@NAME_SHORT@@ Categories=Utility;TextEditor;Development;IDE; <del> MimeType=text/plain;inode/directory; </del> <ins> MimeType=text/plain;inode/directory;application/x-@@NAME@@-workspace; </ins> Actions=new-empty-window; Keywords=vscode;

Related discussion:
text: A Visual Studio Code workspace file is currently recognised in Linux as a normal plain text file. This is because there isn't a MIME type for this file. Applications can provide additional MIME types as described here: Not having a MIME type has a couple of issues, for example the files are shown as plain text files in the GUI, which makes it hard to distinguish source code files from the workspace file. This slows down navigating to a workspace and opening it. Find the workspace in the following screenshot ! It's currently impossible to theme such a file because it's not seen as a different MIME type:
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.461 --<!-- potentialduplicatescomment --
This also means that you can't make double clicking the workspace from a file browser open it in vscode, unless you're OK with all text files opening in vscode, which is probably not what most folks want.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hi can you verify this issue? Check out the previous comment.
I tried to verify this but am not sure how to do this myself. I've not used desktop linux extensively; I tried reinstalling Insiders from the on Lubuntu to see if it associated files with VS Code, but that didn't happen.
Verified by installing insiders from on Ubuntu and was able to see mimetype and set a custom icon ! upon uninstalling it was removed.
Code change:
import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { Emitter, Event } from 'vs/base/common/event'; import { DisposableStore } from 'vs/base/common/lifecycle'; <ins> import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; </ins> const CTX_QUICK_CHAT_IN_PROGRESS = new RawContextKey<boolean>('inlineChat.quickChatInProgress', false);

Related discussion:
text: empty profile open terminal, run or any other command that prints something press to clear the terminal :bug: the keyboard system is waiting for chord to be completed
Code change:
quickSuggestions: false, renderWhitespace: 'none', dropIntoEditor: { enabled: true }, <del> readOnly: true </del> <ins> readOnly: true, fontFamily: 'var(--monaco-monospace-font)' </ins> }; this._editorWidget = this._register(this._instantiationService.createInstance(CodeEditorWidget, this._editorContainer, editorOptions, codeEditorWidgetOptions)); } show(provider: IAccessibleContentProvider): void { const delegate: IContextViewDelegate = { <del> getAnchor: () => this._editorContainer, </del> <ins> getAnchor: () => { return { x: (window.innerWidth / 2) - (DIMENSION_DEFAULT.WIDTH / 2), y: (window.innerHeight / 2) - (this.editorWidget.getContentHeight() / 2) }; }, </ins> render: (container) => { return this._render(provider, container); },

Related discussion:
text: When resizing the windows while the accessible help menu is visible, the help menu slides diagonally: !
Code change:
quickSuggestions: false, renderWhitespace: 'none', dropIntoEditor: { enabled: true }, <del> readOnly: true </del> <ins> readOnly: true, fontFamily: 'var(--monaco-monospace-font)' </ins> }; this._editorWidget = this._register(this._instantiationService.createInstance(CodeEditorWidget, this._editorContainer, editorOptions, codeEditorWidgetOptions)); } show(provider: IAccessibleContentProvider): void { const delegate: IContextViewDelegate = { <del> getAnchor: () => this._editorContainer, </del> <ins> getAnchor: () => { return { x: (window.innerWidth / 2) - (DIMENSION_DEFAULT.WIDTH / 2), y: (window.innerHeight / 2) - (this.editorWidget.getContentHeight() / 2) }; }, </ins> render: (container) => { return this._render(provider, container); },

Related discussion:
text: Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.
Code change:
quickSuggestions: false, renderWhitespace: 'none', dropIntoEditor: { enabled: true }, <del> readOnly: true </del> <ins> readOnly: true, fontFamily: 'var(--monaco-monospace-font)' </ins> }; this._editorWidget = this._register(this._instantiationService.createInstance(CodeEditorWidget, this._editorContainer, editorOptions, codeEditorWidgetOptions)); } show(provider: IAccessibleContentProvider): void { const delegate: IContextViewDelegate = { <del> getAnchor: () => this._editorContainer, </del> <ins> getAnchor: () => { return { x: (window.innerWidth / 2) - (DIMENSION_DEFAULT.WIDTH / 2), y: (window.innerHeight / 2) - (this.editorWidget.getContentHeight() / 2) }; }, </ins> render: (container) => { return this._render(provider, container); },

Related discussion:
text: But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:
Code change:
.conflict-zone-root { background-color: var(--vscode-mergeEditor-change-background); <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </ins> height: 90%; display: flex; align-items: center;

Related discussion:
text: ! The highlighting is important to understand which conflict in the bottom view corresponds to which conflicts in result. I think the change of the color of the dashed border is difficult to notice.