jiebi/CodeConvo huggingface dataset:
Change:
this.validationDisposable = this.contextViewService.showContextView({ getAnchor: () => this.editorContainer, render: container => { <ins> this.editorContainer.style.borderBottomLeftRadius = '0'; this.editorContainer.style.borderBottomRightRadius = '0'; </ins> const validationContainer = append(container, $('.scm-editor-validation-container')); validationContainer.classList.toggle('validation-info', this.validation!.type === InputValidationType.Information); validationContainer.classList.toggle('validation-warning', this.validation!.type === InputValidationType.Warning); validationContainer.classList.toggle('validation-error', this.validation!.type === InputValidationType.Error); <del> validationContainer.style.width = `${this.editorContainer.clientWidth}px`; </del> <ins> validationContainer.style.width = `${this.editorContainer.clientWidth + 2}px`; </ins> const element = append(validationContainer, $('.scm-editor-validation')); const message = this.validation!.message;

Discussion:
Source control warning not aligned on the right hand side with the input field: <img width="473" alt="image" src="https://user-"
Draft PR here but I feel that there is a better way. For whatever reason the editor within SCM input is not as wide as the input it is rendered in—or something like that. Open to ideas!
Here is the updated layout: <img width="567" alt="image" src="https://user-"
Change:
} else if (mime.startsWith('image/') && typeof value === 'string' && mime !== 'image/svg+xml') { // Images in Jupyter are stored in base64 encoded format. // VS Code expects bytes when rendering images. <del> const data = Uint8Array.from(atob(value), c => c.charCodeAt(0)); return new NotebookCellOutputItem(data, mime); </del> <ins> if (typeof Buffer !== 'undefined' && typeof Buffer.from === 'function') { return new NotebookCellOutputItem(Buffer.from(value, 'base64'), mime); } else { const data = Uint8Array.from(atob(value), c => c.charCodeAt(0)); return new NotebookCellOutputItem(data, mime); } </ins> } else if (typeof value === 'object' && value !== null && !Array.isArray(value)) { return NotebookCellOutputItem.text(JSON.stringify(value), mime); } else {

Discussion:
Issue Type: <bBug</bI was working on a notebook with lots of print output for debugging. 10min in, I could not save and got a notification of "Maximum call stack size exceeded". ! The kernel script was still running and printing hefty objects in a loop. I remember once crashing VS Code with long notebook output, so maybe this is related. Console log: Extension version: 2021.8. VS Code version: Code - Insiders 1.59.0-insider (, 2021-07-22T05:13:00.851Z) OS version: Darwin x64 20.5.0 Restricted Mode: No Remote OS version: Linux x64 5.10.25-linuxkit Fetching remote diagnostics for 'dev-container+7b22686f737450617468223a222f55736572732f64696769746172616c642f7265706f732f6465766469762d6d6574726963732d616e642d616e616c79736573222c2273657474696e6773223a7b22636f6e74657874223a226465736b746f702d6c696e7578227d7d' timed out. <details<summarySystem Info</summary Fetching remote diagnostics for 'dev-container+7b22686f737450617468223a222f55736572732f64696769746172616c642f7265706f732f6465766469762d6d6574726963732d616e642d616e616c79736573222c2273657474696e6773223a7b22636f6e74657874223a226465736b746f702d6c696e7578227d7d' timed out. </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Saving while logging long print statements worked fine now.
Change:
if (!hoverController) { return; } <del> this._provider = accessor.get(IInstantiationService).createInstance(HoverAccessibleViewProvider, codeEditor, hoverController); </del> <ins> const keybindingService = accessor.get(IKeybindingService); this._provider = accessor.get(IInstantiationService).createInstance(HoverAccessibleViewProvider, keybindingService, codeEditor, hoverController); </ins> return this._provider; }

Discussion:
Testing the keybinding for verbosity hover over =Shows the keybinding accessibility view of the hover focus to the by clicking A hover for the action shows without the keybinding !
Change:
import { INotebookActionContext, INotebookCellActionContext, NotebookAction, NotebookCellAction, NOTEBOOK_EDITOR_WIDGET_ACTION_WEIGHT, findTargetCellEditor } from 'vs/workbench/contrib/notebook/browser/controller/coreActions'; import { CellEditState } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; import { CellKind, NOTEBOOK_EDITOR_CURSOR_BOUNDARY } from 'vs/workbench/contrib/notebook/common/notebookCommon'; <del> import { NOTEBOOK_CELL_HAS_OUTPUTS, NOTEBOOK_CELL_MARKDOWN_EDIT_MODE, NOTEBOOK_CELL_TYPE, NOTEBOOK_CURSOR_NAVIGATION_MODE, NOTEBOOK_EDITOR_FOCUSED, NOTEBOOK_OUTPUT_INPUT_FOCUSED, NOTEBOOK_OUTPUT_FOCUSED } from 'vs/workbench/contrib/notebook/common/notebookContextKeys'; </del> <ins> import { NOTEBOOK_CELL_HAS_OUTPUTS, NOTEBOOK_CELL_MARKDOWN_EDIT_MODE, NOTEBOOK_CELL_TYPE, NOTEBOOK_CURSOR_NAVIGATION_MODE, NOTEBOOK_EDITOR_FOCUSED, NOTEBOOK_OUTPUT_INPUT_FOCUSED, NOTEBOOK_OUTPUT_FOCUSED, NOTEBOOK_CELL_EDITOR_FOCUSED } from 'vs/workbench/contrib/notebook/common/notebookContextKeys'; </ins> const NOTEBOOK_FOCUS_TOP = 'notebook.focusTop'; const NOTEBOOK_FOCUS_BOTTOM = 'notebook.focusBottom';

Discussion:
mentioned that the current keybinding for this controls speech rate for jaws users on windows should be used for code chat next code block and go to next /previous cell
related ctrl+pagedown/pageup are currently bound to next/previous editor
shouldn't those have context keys though that will mean this can still work for notebook cells?
next/previous editor don't have context keys for those keybindings, so it will be a behavior change. We could add the bindings just for SR mode if you don't think those users would be annoyed by it.
what do you think? I also don't want to surprise users with this behavior change.
I don’t think this is a surprise change. If we weigh the tradeoff, going with the new keybindings avoiding SR keys might be more beneficial in the long run.
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import * as assert from 'assert'; import { Suite } from 'mocha'; </ins> import * as vscode from 'vscode'; import { TestFS } from './memfs'; <del> import * as assert from 'assert'; </del> <ins> export function flakySuite(title: string, fn: (this: Suite) => void): Suite { return suite(title, function () { // Flaky suites need retries and timeout to complete // e.g. because they access the file system which can // be unreliable depending on the environment. this.retries(3); this.timeout(1000 * 20); // Invoke suite ensuring that `this` is // properly wired in. fn.call(this); }); } </ins> export function rndName() { return Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10);

Discussion:
Couple of milestones ago I have skipped these tests becuase they were failing. I am not sure if I created the issue at the moment but I am doing that now. Sorry if I did not ping sooner. Code pointer
I had to revert this change: I think they cause our browser integration tests to hang/fail:
Change:
private readonly _onDidInitiateWorkspaceTrustRequest = this._register(new Emitter<WorkspaceTrustRequestOptions | undefined>()); readonly onDidInitiateWorkspaceTrustRequest = this._onDidInitiateWorkspaceTrustRequest.event; <ins> private readonly _onDidInitiateWorkspaceTrustRequestOnStartup = this._register(new Emitter<void>()); readonly onDidInitiateWorkspaceTrustRequestOnStartup = this._onDidInitiateWorkspaceTrustRequestOnStartup.event; </ins> constructor( @IConfigurationService private readonly configurationService: IConfigurationService, @IWorkspaceTrustManagementService private readonly workspaceTrustManagementService: IWorkspaceTrustManagementService

Discussion:
I created a brand new VM and attached remote-ssh to it, then opened my folder on it. I clicked to trust the folder, then immediately after I was prompted by the terminal to trust the folder again. Every time I open a new folder thereafter I'm again double prompted for trust.
this is how we use the API, is promise for the original prompt not being shared with successive requests or something?
All callers of should be sharing the same promise. I will try to set up a repro today and see if I can reproduce the problem locally.
Here is what is happening: initial workspace trust modal dialog is being displayed there is another workspace trust dialog displayed due to the call the workspace will actually resolve the promise and in the background you can see the terminal is initiated The workspace trust request dialog is not being dismissed. I do have couple of ideas that I will discuss with
The fix will be available in Friday's Insiders release.
Change:
padding-right: 5px; /* with tab sizing shrink/fixed and badges, we want a right-padding because the close button is hidden */ } <ins> .monaco-workbench .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sizing-shrink:not(.tab-actions-left):not(.tab-actions-off) .tab-label { padding-right: 5px; /* ensure that the gradient does not show when tab actions show https://github.com/microsoft/vscode/issues/189625*/ } </ins> .monaco-workbench .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sticky-compact:not(.has-icon) .monaco-icon-label { text-align: center; /* ensure that sticky-compact tabs without icon have label centered */ }

Discussion:
hover over editor tabs observe some kind of shadow dropping over the text
This only reproduces with set to and tabs enabled in general. Hovering over any tab shows the white shadow at the end of the label. With this setting, every tab label has a element to draw a linear gradient (): <img width="400" alt="image" src=""A tab itself is a container of a label and the toolbar with the close button. The close button is set to to not take more space than needed. When you hover, the toolbar is made visible, actually pushing the element into view having the described effect: <img width="504" alt="image" src=""I actually think this is an OK behaviour for when the tab is small enough that the label cannot full show, and that was the intention. However, it is a bit strange that this would happen even for a tab that shows fully and has enough space. If someone wants to chime in to take a look with a reasonably small change, opening for help wanted. But may decide to close out of scope as this does not seem like it was ever a regression.
<!-- 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!
Change:
start(args: ParsedArgs, userEnv: IProcessEnvironment): TPromise<void> { return this.channel.call('start', { args, userEnv }); } <ins> getMainProcessId(): TPromise<number> { return this.channel.call('get-main-process-id', null); } </ins> } export class LaunchService implements ILaunchService {

Discussion:
This can happen when code is already running and you start it again from the command line: The process that is started is killed very early after sending a IPC message to the running instance and that running instance is then trying to restore/focus the last active window which often fails. Related: As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Pushed a workaround.
Reopening, using the () workaround causes issues as it will undock windows it seems.
This happens EVERY time for me - on all 3 machines I use it on, Windows 7 and Windows 10.
As a workaround if you have access to the windows registry: find change its value to (decimal) restart windows
Just tried the suggested workaround and it did not work. Using Windows 10 Home
I've been hit with this bug suddenly after having style execution from WinSCP work flawlessly for months. On top of that, the suggested workaround doesn't work as is nowhere to be found in my registry. Reading this it looks like the issue was fixed but has there been a regression?
Seems to have re-emerged for me. On first launch of VSCode it will focus on top of other windows, but on subsequent launches it stays in the background and flashes in the taskbar. I searched the registry but can't find any reference to . I'm on Win10 Build
Must have made the rookie mistake of not starting the search in the registry root earlier. It turns out there are several hits and the first one in seems to have worked.
I started running into this issue today. Started when I would open a new window from my current window and the new window would not appear on screen, only in the taskbar. Upon restarting the PC, no windows now appear. Tried the workaround but with no luck. Windows10 Build
Update: I made it to work by right clicking the task bar editor thumbnail of VSC and clicking on move. This made my cursor move to the edge of the desktop. I then dragged the corner of the VSC window to bring it to the center. It looks like VSC window was off the desktop boundary for some reason I have made registry changes to hkeylocalmachine and hkeycurrentuser as mentioned but it still doesn't work. Any other suggestions? Reinstalling doesn't fix the issue either.
This is happening to me also since the previous 2 releases. Changing the value of did not help
Change:
<string>#082050</string> <key>selection</key> <string>#770811</string> <ins> <key>guide</key> <string>#002952</string> </ins> </dict> </dict> <dict>

Discussion:
Testing on a MacBook Pro Retina display with brightness 2 steps below max while using a power adapter. This is my usual setting a regularly lit environments. In the following themes the indentation guides should be changed to improve their visibility: [x]  Abyss [x]  High Contrast [x]  Monokai In the following themes the indentation guides are subtle and easy to miss. However, changing those is optional. [x]  Dark (and Dark+)
I am using the color from the theme, 100% the same as . owns the Dark and Dark+ themes (including the color):
Assigning to the UX team to decide on changes to the default colors.
Some of the reported themes (Dark, Dark+, High Contrast) are owned by us. Others (Abyss, Monokai) are cloned and packaged along with VS Code. It means indirectly we own them and have to maintain them. So we should provide proper color for indent guides for all these themes. Can you please go through all our default packaged themes and come with a nice indentation guides color ? Note: TM theme setting to use for identation guides is . Also, as mentioned in description, except reported themes others look good to me Abyss Dark Dark+ HighContrast Monokai
Reopening until PR is merged in
Moving this to September milestone, since it is too late to make into August
Change:
const focused = this.getFocus(); const focus = focused.length ? focused[0] : null; <del> if (this.view.elementTop(index) >= this.view.getScrollTop()) { return this.view.updateElementHeight(index, size, index); } </del> const anchorFocusedSetting = this.configurationService.getValue(NotebookSetting.anchorToFocusedCell); const allowScrolling = this.configurationService.getValue(NotebookSetting.scrollToRevealCell) !== 'none'; const scrollHeuristic = allowScrolling && anchorFocusedSetting === 'auto' && this.view.elementTop(index) < this.view.getScrollTop();

Discussion:
Testing Provided I understand the setting, the focused cell shouldn't be able to scroll off the page without user input as I've said to anchor the focused cell: ! I was expecting as the setting said, for the selected cell to remain steady and not move at all, while the content above changed and the scroll position was adjusted each time.
I think I might be seeing , scrolling down to show the full cell below including its output would keep it stable.
The anchoring also doesn't work when both cells are fully in the viewport: !
I've noticed that the anchoring works when you scroll the resizing cell off the viewport and then scroll back. If the resizing cell continues to be in view, then the behavior of this bug remains.
This seems to be working for me for some reason if the cell underneath the executing cell has a long output that causes a scroll bar. !
yeah this is completely broken after my late change yesterday, sorry about that
should work now if you and/or want to try playing around with that a bit
Would auto have the same behavior as true in this case?
no, we left auto as the old behavior because we couldn't decide on a good default behavior so we're looking to get some feedback with the setting. auto is currently: If the cell being resized is partially visible at the top of the viewport, anchor to the focused cell. Otherwise anchor to the resizing cell.
see I think with the user's ability to select what cell is focused after execution, we should just always anchor to the focused cell, regardless of whether it's fully or partially visible. An extra setting is just complexity.
OK, I just wanted to make sure you still felt that way after trying it out first hand (I'm not a fan of that behavior in certain senarios)
Change:
import { IExtHostTerminalService } from 'vs/workbench/api/common/extHostTerminalService'; import { Emitter, Event } from 'vs/base/common/event'; import { IExtensionActivationHost, checkActivateWorkspaceContainsExtension } from 'vs/workbench/api/common/shared/workspaceContains'; <ins> import { isEqualOrParent } from 'vs/base/common/extpath'; import { isLinux } from 'vs/base/common/platform'; </ins> interface ITestRunner { /** Old test runner API, as exported from `vscode/lib/testrunner` */

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --Steps to Reproduce: the test sample to "Run Extension Tests" window opens, and immediately closes. VS Code is orphaned in a debugging state until you manually stop it. Happens using both js-debug and node-debug <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: N/A
Other than adding the stopDebugging API I haven't changed anything in VS Code. Could you please do a bisect for finding the regression. Thanks.
I cannot reproduce this on macOS... will try on Windows. no need to investigate for now...
I cannot reproduce on macOS and Windows. Does problem reproduce after reboot?
I can repro this on OSX and Windows, but discovered this is only when the web worker extension host is enabled cc Removing since this won't affect end users yet
great find.
I forgot about this issue and hit it again today until I realized what was happening This is not related to debugging, since it also happens when I run my tests from the command line.
I ran into this yesterday and spent a lot of time on this not realizing that I had webWorker EH on, synced to all my machines. As discussed the other day, instead of "extensions.webWorker" being a setting it should be a command line option. That way it can be defined in launch configs and will result in a nicer development experience.
I fully agree. Ran into the same issue... My current solution to avoid having "extensions.webWorker" spread like a virus is to define it as a workspace setting.
The problem is that we have two distinct extension hosts (the nodejs and the web worker one), and they both believe they are solely responsible for running extension tests. In this case, the web worker extension host begins executing, attempts to load the , which throws since it doesn't run correctly in a web worker, so it communicates to the main thread that it finished with running the extension tests and that it should exit with a certain exit code. In the meantime, the nodejs extension host also loads the same and proceeds executing the tests.

But the renderer process exits on the first call to exit, which comes from the web worker extension host. So it appears that introduced via from is not sufficient anymore, since both extension hosts see that there is an extension test to execute on the protocol:
thank you
Change:
// --- debug support new ApiCommand( 'vscode.executeInlineValueProvider', '_executeInlineValueProvider', 'Execute inline value provider', <del> [ApiCommandArgument.Uri, ApiCommandArgument.Range], </del> <ins> [ ApiCommandArgument.Uri, ApiCommandArgument.Range, new ApiCommandArgument<types.InlineValueContext, IInlineValueContextDto>('context', 'An InlineValueContext', v => v && typeof v.frameId === 'number' && v.stoppedLocation instanceof types.Range, v => typeConverters.InlineValueContext.from(v)) ], </ins> new ApiCommandResult<languages.InlineValue[], vscode.InlineValue[]>('A promise that resolves to an array of InlineValue objects', result => { return result.map(typeConverters.InlineValue.to); })

Discussion:
<!-- 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: 1.81.1 OS Version: any Steps to Reproduce: extension code, call vscode.commands.executeCommand('vscode.executeInlineValueProvider',('c:/foo'),new vscode.Range(0, 0, 1, 1)); promise is rejected with Error: command '_executeInlineValueProvider' not found I am developing an extension, and was not interested in this specific command, but noticed it was missing when I was looking for an example of a debug related built-in command. I have no use for the command, I am just reporting it, because its in the the built-in commands wiki.
Looks like this was never implemented, the only commit that contains that string is do you have extra context here, should this be removed or fixed up?
I don't have any extra context but I suppose it would make sense for that command to exist?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to 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!
do we automatically add these api commands for all language providers or only if they need to exist for some specific scenario?
For things in we have them upfront but for other providers we don't have strict rules.

It's fine to go by request or to treat it as FR
For verification, the only implementation of this API that I am aware of is in java-debug, so you can write an extension that calls and call it while debugging java, or add a dummy provider like this