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?: 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: Insiders OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

Related discussion:
text: } private _updateEverything(): void { <del> this._visibleCells.forEach(cell => cell.dispose()); this._visibleCells.clear(); this._updateVisibleCells({ added: this._observer.visibleCells, removed: [] }); </del> <ins> const newCells = this._observer.visibleCells.filter(cell => !this._visibleCells.has(cell.handle)); const visibleCellHandles = new Set(this._observer.visibleCells.map(item => item.handle)); const currentCellHandles = Array.from(this._visibleCells.keys()); const removedCells = currentCellHandles.filter(handle => !visibleCellHandles.has(handle)); const itemsToUpdate = currentCellHandles.filter(handle => visibleCellHandles.has(handle)); this._updateVisibleCells({ added: newCells, removed: removedCells.map(handle => ({ handle })) }); itemsToUpdate.forEach(handle => this._visibleCells.get(handle)?.update()); </ins> } <del> private _updateVisibleCells(e: ICellVisibilityChangeEvent): void { </del> <ins> private _updateVisibleCells(e: { added: CellViewModel[]; removed: { handle: number }[]; }): void { </ins> const vm = this._notebookEditor.viewModel; if (!vm) { return;
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 <!-- 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 OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

Related discussion:
text: this._register(this._cell.model.onDidChangeOutputs(() => this._updateSoon())); } <ins> public update(): void { this._updateSoon(); } </ins> private _updateSoon(): void { // Wait a tick to make sure that the event is fired to the EH before triggering status bar providers this._register(disposableTimeout(() => {
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 <!-- 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 OS Version: Mac Basically when i have a statusbar item (extension that contributes statusbar items), VS Code re-creates all of the statusbar items for all cells. This causes ALL statubar items in all cells to flicker (as its destroyed and re-created) & we also end up with duplicates. /cc Flickering UI Duplicate statusbar items See below (from latest VS Code Insiders, can also replicate in latest main branch) Note how we end up with two language pickers in statusbar. ! After the fix (re-use instead of re-creating & only create what we need): !
Thought I had squashed all of these. Thanks for the PR!
The power tools don't seem to provide line numbers anymore so I tried switching the language mode around to repro and couldn't so I'm not sure if that's good enough for verification
I think it's sufficient to mess around with it and not see any dupes. And there were random reports of dupes earlier and I haven't heard that in awhile.

Related discussion:
text: override dispose() { super.dispose(); <ins> this._activeToken?.dispose(true); </ins> this._notebookViewModel.deltaCellStatusBarItems(this._currentItemIds, [{ handle: this._cell.handle, items: [] }]); this._currentItemLists.forEach(itemList => itemList.dispose && itemList.dispose());
Code change:
Version: 1.58.0-insider Commit: Date: 2021-06-16T05:18:57.982Z Electron: 12.0.11 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Linux x64 5.11.0-18-generic After starting up VS Code I got a modal dialog telling me about an unusual line delimiter. It didn't tell me about the file this is about. ! After accepting to fix, I saw where the problem was ! I find the dialog too heavy, especially on startup. I would need to see the code to find out what's the issue here. E.g. in our case, this is in a test, so might be intended Maybe have a warning triage next to 'LF' in the status bar? When I click ignore for this file, how can I unignore the file?
I agree this is pretty weird. The prompt comes from a code editor contribution which executes only when a code editor widget is instantiated and shows the problematic file. I think that this normally works fine, but in this case I believe the problematic file was opened, the dialog was shown, and then the "Release Notes" editor opened under the prompt and changed the active editor from under the prompt. I agree with the feedback here, but I'm not sure what to do. Maybe we could make the "Release Notes" editor wait until all confirm dialogs have been closed before showing itself or that the workbench starts directly with that editor after a release? Regarding converting this to a passive indicator in the status bar: I don't think that would be wise. Having this unusual line terminator will lead to semantic tokens, jump to definition and all kind of language features to become off. Here is the background:
Maybe instead of a modal dialog this could be shown somewhere in the editor area? Almost like the trust banner but instead of showing to the top of the window, showing right above the editor but still inside the editor? ! As for release notes, I think we are investigating to move away from using an editor and using something else but I cannot find the issue now. Arguably this can happen in other cases too I guess, e.g. when I open a file which loads slow and I manage to open another editor over it?
Well, easiest fix is to add the file name into the dialog, I would argue then it doesn't really matter which editor is active.
PR is up to change the dialog just a bit (): !

Related discussion:
text: import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { ITextModel } from 'vs/editor/common/model'; import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; <ins> import { basename } from 'vs/base/common/resources'; </ins> const ignoreUnusualLineTerminators = 'ignoreUnusualLineTerminators';
Code change:
According to the documentation, if calling show(true), the terminal will be made visible but it won't capture the keyboard focus. I also remember in the past this worked. For some months already I noticed that regardless of how I call show, the focus is always taken. Anything changed? Is there already an issue that you tracking for this? Am I doing anything wrong? Related to this, if we won't manage to fix this behavior, how can we make key bindings for commands to be recognized even when the terminal has the focus? For example, when having focus in the terminal, if I press F5 debugging will start. The terminal will not try to write something for "F5". But if I run another key combination that I defined for some extension command, the terminal will react to the key combination (will try to write something) and the command will not be triggered (unless focus is somewhere else). We have this issue in the CMake Tools repository and the user would be happy if we fix this problem either way.
Hey, I would like to work on this issue. Could you give me any pointers? Where should I start?
this one's a little involved as it needs an extension to trigger the issue, you'd be better off finding an issue with the help wanted label.
Okay, thanks!
Tried this in an extension after making sure I had a terminal open: And the focus moved into the terminal.
did you have focus in the terminal before running that? preserve focus returns the focus to whatever was focused before. I'm unable to reproduce the problem using the exact code you mention above. Could you please include a gif? !
!

Related discussion:
text: } else { this._onDidChangeViewWelcomeState.fire(); } <del> if (!this._terminalService.activeInstance?.shellLaunchConfig.extHostTerminalId) { // showPanel is already called with !preserveFocus // when extension host terminals are created this._terminalGroupService.showPanel(true); } </del> <ins> // we don't know here whether or not it should be focused, so // defer focusing the panel to the focus() call // to prevent overriding preserveFocus for extensions this._terminalGroupService.showPanel(false); </ins> if (hadTerminals) { this._terminalGroupService.activeGroup?.setVisible(visible); }
Code change:
According to the documentation, if calling show(true), the terminal will be made visible but it won't capture the keyboard focus. I also remember in the past this worked. For some months already I noticed that regardless of how I call show, the focus is always taken. Anything changed? Is there already an issue that you tracking for this? Am I doing anything wrong? Related to this, if we won't manage to fix this behavior, how can we make key bindings for commands to be recognized even when the terminal has the focus? For example, when having focus in the terminal, if I press F5 debugging will start. The terminal will not try to write something for "F5". But if I run another key combination that I defined for some extension command, the terminal will react to the key combination (will try to write something) and the command will not be triggered (unless focus is somewhere else). We have this issue in the CMake Tools repository and the user would be happy if we fix this problem either way.
Hey, I would like to work on this issue. Could you give me any pointers? Where should I start?
this one's a little involved as it needs an extension to trigger the issue, you'd be better off finding an issue with the help wanted label.
Okay, thanks!
Tried this in an extension after making sure I had a terminal open: And the focus moved into the terminal.
did you have focus in the terminal before running that? preserve focus returns the focus to whatever was focused before. I'm unable to reproduce the problem using the exact code you mention above. Could you please include a gif? !
!

Related discussion:
text: // Only focus the terminal if the activeElement has not changed since focus() was called // TODO hack if (document.activeElement === activeElement) { <del> this._focus(); </del> <ins> this._terminalGroupService.showPanel(true); </ins> } })); return; } <del> this._focus(); } private _focus() { this._terminalService.activeInstance?.focusWhenReady(); </del> <ins> this._terminalGroupService.showPanel(true); </ins> } override shouldShowWelcome(): boolean {
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: globalStorageHome: URI; workspaceStorageHome: URI; useHostProxy?: boolean; <ins> skipWorkspaceStorageLock?: boolean; </ins> } export interface IStaticWorkspaceData {
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: return workspaceStorageURI; } <ins> if (this._environment.skipWorkspaceStorageLock) { this._logService.info(`Skipping acquiring lock for ${workspaceStorageURI.fsPath}.`); return workspaceStorageURI; } </ins> const workspaceStorageBase = workspaceStorageURI.fsPath; let attempt = 0; do {
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: } // Run Extension Host as fork of current process <del> this._extensionHostProcess = fork(FileAccess.asFileUri('bootstrap-fork', require).fsPath, ['--type=extensionHost'], opts); </del> <ins> this._extensionHostProcess = fork(FileAccess.asFileUri('bootstrap-fork', require).fsPath, ['--type=extensionHost', '--skipWorkspaceStorageLock'], opts); </ins> // Catch all output coming from the extension host process type Output = { data: string, format: string[] };
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: import { realpath } from 'vs/base/node/extpath'; import { IHostUtils } from 'vs/workbench/api/common/extHostExtensionService'; import { RunOnceScheduler } from 'vs/base/common/async'; <ins> import { boolean } from 'vs/editor/common/config/editorOptions'; </ins> import 'vs/workbench/api/common/extHost.common.services'; import 'vs/workbench/api/node/extHost.node.services'; interface ParsedExtHostArgs { uriTransformerPath?: string; <ins> skipWorkspaceStorageLock?: boolean; </ins> useHostProxy?: string; }
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: string: [ 'uriTransformerPath', 'useHostProxy' <ins> ], boolean: [ 'skipWorkspaceStorageLock' </ins> ] }) as ParsedExtHostArgs;
Code change:
In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .

Related discussion:
text: // setup things patchProcess(!!initData.environment.extensionTestsLocationURI); // to support other test frameworks like Jasmin that use process.exit (https://github.com/microsoft/vscode/issues/37708) initData.environment.useHostProxy = args.useHostProxy !== undefined ? args.useHostProxy !== 'false' : undefined; <ins> initData.environment.skipWorkspaceStorageLock = boolean(args.skipWorkspaceStorageLock, false); </ins> // host abstraction const hostUtils = new class NodeHost implements IHostUtils {