jiebi/CodeConvo huggingface dataset:
Code change:
disturl "https://electronjs.org/headers" target "29.4.0" <del> ms_build_id "9593362" </del> <ins> ms_build_id "9728852" </ins> runtime "electron" build_from_source "true"

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:
assert.deepStrictEqual(cellList.getViewScrollBottom(), 210); // scroll to 5 <ins> cellList.updateElementHeight2(viewModel.cellAt(0)!, 50); </ins> cellList.scrollTop = 5; assert.deepStrictEqual(cellList.scrollTop, 5); assert.deepStrictEqual(cellList.getViewScrollBottom(), 215);

Related discussion:
text: Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.
Code change:
this._currentName = currentName; this._input.domNode.value = currentName; <ins> this._input.domNode.setAttribute('selectionStart', selectionStart.toString()); this._input.domNode.setAttribute('selectionEnd', selectionEnd.toString()); </ins> this._input.domNode.size = Math.max((where.endColumn - where.startColumn) * 1.1, 20); // determines width const disposeOnDone = new DisposableStore();

Related discussion:
text: Select a portion of a variable name Press F2 Previously, the rename widget would open with the same substring highlighted. It's helpful to quickly rename one subword in a variable name, for example. Now, the full contents of the input in the rename widget are highlighted initially. I don't know who owns this but it looks like you touched it recently
<!-- 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!
Code change:
// create the suggestion resolver if (typeof provider.resolveCompletionItem !== 'function') { this._resolveCache = Promise.resolve(); <ins> this._isResolved = true; </ins> } } // resolving get isResolved() { <del> return Boolean(this._resolveCache); </del> <ins> return Boolean(this._isResolved); </ins> } private _resolveCache?: Promise<void>; <ins> private _isResolved?: boolean; </ins> async resolve(token: CancellationToken) { if (!this._resolveCache) { const sub = token.onCancellationRequested(() => { this._resolveCache = undefined; <ins> this._isResolved = false; </ins> }); this._resolveCache = Promise.resolve(this.provider.resolveCompletionItem!(this.completion, token)).then(value => { Object.assign(this.completion, value); <ins> this._isResolved = true; </ins> sub.dispose(); }, err => { if (isPromiseCanceledError(err)) { // the IPC queue will reject the request with the // cancellation error -> reset cached this._resolveCache = undefined; <ins> this._isResolved = false; </ins> } }); }

Related discussion:
text: Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified
Code change:
// create the suggestion resolver if (typeof provider.resolveCompletionItem !== 'function') { this._resolveCache = Promise.resolve(); <ins> this._isResolved = true; </ins> } } // resolving get isResolved() { <del> return Boolean(this._resolveCache); </del> <ins> return Boolean(this._isResolved); </ins> } private _resolveCache?: Promise<void>; <ins> private _isResolved?: boolean; </ins> async resolve(token: CancellationToken) { if (!this._resolveCache) { const sub = token.onCancellationRequested(() => { this._resolveCache = undefined; <ins> this._isResolved = false; </ins> }); this._resolveCache = Promise.resolve(this.provider.resolveCompletionItem!(this.completion, token)).then(value => { Object.assign(this.completion, value); <ins> this._isResolved = true; </ins> sub.dispose(); }, err => { if (isPromiseCanceledError(err)) { // the IPC queue will reject the request with the // cancellation error -> reset cached this._resolveCache = undefined; <ins> this._isResolved = false; </ins> } }); }

Related discussion:
text: so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected
Code change:
readonly outputScrolling?: boolean; readonly outputLinkifyFilePaths?: boolean; readonly minimalError?: boolean; <ins> readonly readonly?: boolean; </ins> } const defaultConfigConstants = Object.freeze({

Related discussion:
text: Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by
Code change:
export type SocketCloseEvent = NodeSocketCloseEvent | WebSocketCloseEvent | undefined; <ins> export interface SocketTimeoutEvent { readonly unacknowledgedMsgCount: number; readonly timeSinceOldestUnacknowledgedMsg: number; readonly timeSinceLastReceivedSomeData: number; } </ins> export interface ISocket extends IDisposable { onData(listener: (e: VSBuffer) => void): IDisposable; onClose(listener: (e: SocketCloseEvent) => void): IDisposable;

Related discussion:
text: I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).
Code change:
export type SocketCloseEvent = NodeSocketCloseEvent | WebSocketCloseEvent | undefined; <ins> export interface SocketTimeoutEvent { readonly unacknowledgedMsgCount: number; readonly timeSinceOldestUnacknowledgedMsg: number; readonly timeSinceLastReceivedSomeData: number; } </ins> export interface ISocket extends IDisposable { onData(listener: (e: VSBuffer) => void): IDisposable; onClose(listener: (e: SocketCloseEvent) => void): IDisposable;

Related discussion:
text: this resulted in the core invoking on the SSH extension and the SSH extension replied with a new port i.e. instead of the previous . the extension host connection immediately closed at with code , indicating that perhaps the previous tunnel at was killed as part of invoking . Precisely 20 minutes later, at , both management and extension host connections receive a event from Chromium. I can't quite explain the first timeout, why would the server not acknowledge a message within 20 seconds? But the timing of the second disconnection seems to indicate to me that after 20 min of idleness, the underlying connection is closed. Anyone could be closing it: either on the client side by Chromium or the OS, either on the server side by nodejs or the OS, either by the SSH tunnel timing out. For the second disconnection I think we might need to do something to tackle . For a long time the terminal was doing a heartbeat mechanism which resulted in data being sent over the wire (and that would not make the connection idle), but that was fixed via Right now, if you are really idle in a window, the underlying connection will be idle too and I think the OS or someone closes it as idle after 20 minutes.
My best guess is some other weird optimization where network requests don't even get delivered when an app is in the background. I've noticed this in windows that are not focused
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Code change:
<del> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { // https://github.com/microsoft/vscode/issues/144944 /** * Impacts the behavior and appearance of the validation message. */ export enum InputBoxValidationSeverity { Info = 1, Warning = 2, Error = 3 } /** * Object to configure the behavior of the validation message. */ export interface InputBoxValidationMessage { /** * The validation message to display. */ readonly message: string; /** * The severity of the validation message. * NOTE: When using `InputBoxValidationSeverity.Error`, the user will not be allowed to accept (hit ENTER) the input. * `Info` and `Warning` will still allow the InputBox to accept the input. */ readonly severity: InputBoxValidationSeverity; } export interface InputBoxOptions { /** * The validation message to display. This will become the new {@link InputBoxOptions#validateInput} upon finalization. */ validateInput2?(value: string): string | InputBoxValidationMessage | undefined | null | Thenable<string | InputBoxValidationMessage | undefined | null>; } export interface InputBox { /** * The validation message to display. This will become the new {@link InputBox#validationMessage} upon finalization. */ validationMessage2: string | InputBoxValidationMessage | undefined; } } </del>

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --We already have this feature in Core: where you can return where . Truth be told, this already works in API today though it's not officially a part of the API today (so it could change at any moment). For example, I can do: <img width="738" alt="image" src="https://user-"with it goes from: to it goes from: to
ref
Created a TPI so moving this to April for Finalization.
Code change:
return parsedPath.ext.slice(1); default: { // dirname and dirname(arg) const n = variable === 'dirname' ? 0 : parseInt(arg); <del> const nthDir = this.getNthDirname(parsedPath, n); </del> <ins> const nthDir = this.getNthDirname(relevantPath, n); </ins> if (nthDir) { return nthDir; }

Related discussion:
text: Currently, the editor does not support customizing file labels in a way that would allow filenames to be prefixed with the name of the application or folder from the start of the path. This limitation affects projects structured in a monorepo setup, particularly when files are deeply nested within application-specific directories. Supporting negative indices for could solve this problem. This would enable accessing folder names starting from the beginning of the path. Implementing negative indices would cater to the needs of projects with files at various nesting levels within their structure.
Is the reasoning not the other way round or am I misunderstanding how it currently works? E.g. I'd like to access last 2 parts of the path, but the description of the settings suggests that only the single final and the starting folders can be accessed.
For the following path you will get the following values: Path: : : : : With negative indices: : : :
Here is an example of the mono repo: It has a root and multiple projects in the folder. It is common to make changes in multiple "packages" at once, and it would be convenient if we could identify files by the . Example: -
Verification steps: a custom editor label. The template should include , for which is a negative number. For example, add in , item: value: a file which matches the pattern specified in step 1. For the example specified in step 1: every file matches the pattern editor tab should have set the correct folder name for . Here an explanation on how negative indices work: For the example specified in step 1: the name of the editor in the tab should start with the top level folder the file is located in. In the vscode repo the file would have the custom name
I have followed the steps for the verification and the settings file is renamed to . The TS files are renamed correctly to . Is this expected?
Code change:
readonly token?: CancellationToken; } <del> /*marked.* </del> <ins> /** </ins> * Renders a string of markdown as a document. * * Uses VS Code's syntax highlighting code blocks.

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. --- VS Code Version: Version: 1.93.0-insider (user setup) Commit: Date: 2024-09-04T13:13:15.344Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0. OS Version: Windows 11 Insiders Steps to Reproduce: in the first paragraph doesn't appear to be a link, which I was surprised about: ! I hover over it, I see it's supposed to be a link, but clicking on it does nothing: ! The other docs links at the bottom of the playground appear correctly as links and do open when I click on them: !
This seems related to the bookmark issue we had in the release notes. The other bookmark links in the interactive playground don't work either.
Fixed the toc links. Need another fix for the documentation link too (which use command uris)
The Editor Playground is not showing at all anymore in the latest insiders. When selecting the Editor Playground menu item, a black editor comes up.
hm working from oss builds. Insiders, it seems like the error is:
Actually unrelated. Seems like a duplicate of and fixed by
Code change:
constructor() { super({ id: SETTINGS_EDITOR_COMMAND_FOCUS_CONTROL, <del> precondition: CONTEXT_SETTINGS_ROW_FOCUS, </del> <ins> precondition: ContextKeyExpr.and(CONTEXT_SETTINGS_EDITOR, CONTEXT_SETTINGS_ROW_FOCUS), </ins> keybinding: { primary: KeyCode.Enter, weight: KeybindingWeight.WorkbenchContrib,

Related discussion:
text: On Safari/Codespace Open a notebook Open settings Switch to notebook Press enter https://user-
Code change:
@IInstantiationService private readonly instantiationService: IInstantiationService, @ISharedProcessService private readonly sharedProcessService: ISharedProcessService, @IProgressService private readonly progressService: IProgressService, <del> @ILabelService private readonly labelService: ILabelService, @IUriIdentityService private readonly uriIdentityService: IUriIdentityService </del> <ins> @ILabelService private readonly labelService: ILabelService </ins> ) { super();

Related discussion:
text: a JS file: to definition on Bug I see this scary notification: <img width="671" alt="Screen Shot 2022-07-26 at 2 31 10 PM" src="https://user-"In this case, the user was likely just trying to view the file Would it be possible to either: show this notification when saving? open these file as ?
This came in via from and I think is not good. This also reminds me that when debugging you may end up in a file from the installation dir. I think we should probably revert the change for now and think about a better solution unless there are objections.
I agree. Maybe pursue your earlier suggestion of opening all installation directory files in readonly mode. Perhaps combine with a scary warning if you save a new file in there.
Code change:
# This makes sure the model is included in the package !@vscode/vscode-languagedetection/model/** <ins> # Ensure only the required telemetry pieces are loaded in web to reduce bundle size @microsoft/1ds-core-js/** @microsoft/1ds-post-js/** @microsoft/applicationinsights-core-js/** @microsoft/applicationinsights-shims/** !@microsoft/1ds-core-js/dist/ms.core.min.js !@microsoft/1ds-post-js/dist/ms.post.min.js !@microsoft/applicationinsights-core-js/browser/applicationinsights-core-js.min.js !@microsoft/applicationinsights-shims/dist/umd/applicationinsights-shims.min.js </ins>

Related discussion:
text: We very likely do not need to ship all of this in the web bits: This was already once done before in , and when dependencies got renamed this was once again forgotten about.
Code change:
})); } <ins> clearInput(): void { this.contentDisposables.clear(); this.transientDisposables.clear(); super.clearInput(); } </ins> focus(): void { if (this.activeElement) { this.activeElement.focus();

Related discussion:
text: Issue Type: <bBug</bdeveloper tools themes Everything appears to work as normal, but the console gets flooded with errors. VS Code version: Code - Insiders 1.36.0-insider (, 2019-06-14T10:36:51.530Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ vscode-eslint1.9.0 gitlens9.8.2 vsc-material-theme2.9.0 remote-containers0.61.0 remote-ssh-edit-nightly2019.6. remote-ssh-explorer-nightly2019.6. remote-ssh-nightly2019.6. vscode-typescript-tslint-plugin1.1.0 debugger-for-chrome4.11.3 vscode-docker0.6.2 material-icon-theme3.8.0 polacode0.3.2 vscode-sort-json1.13.0 </details<!-- generated by issue reporter --
I can't repo this. Which developer tools and theme are you talking about specifically?
I tried repoing this again and it appears that this error is related to installing a new theme. Here are some better repo steps: developer tools themes (no errors) a theme themes (errors even if it is one of the themes shipped with VS code) The errors go away after a reload, but installing a theme does not tell me a reload is required.
Ok, with the extensions view open, I sometimes see Does not cause seem to cause any actual problems
I get that as well sometimes, but do you not get the webview must be attached to the DOM error as well?
I can reproduce it. Steps: on any extension to load it's Readme in an editor that editor theme (this triggers the webview error) step 1 (this triggers the guestInstanceId error)