jiebi/CodeConvo huggingface dataset:
Code change:
this._register(Event.debounce(testProfiles.onDidChange, (_last, e) => e)(() => { const obj: Record</* controller id */string, /* profile id */ number[]> = {}; <del> for (const { controller, profiles } of this.testProfiles.all()) { obj[controller.id] = profiles.filter(p => p.isDefault).map(p => p.profileId); </del> <ins> for (const group of [TestRunProfileBitset.Run, TestRunProfileBitset.Debug, TestRunProfileBitset.Coverage]) { for (const profile of this.testProfiles.getGroupDefaultProfiles(group)) { obj[profile.controllerId] ??= []; obj[profile.controllerId].push(profile.profileId); } </ins> } this.proxy.$setDefaultRunProfiles(obj);

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?: 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.86 OS Version: macOS 14.3 Steps to Reproduce: run profile programmatically with isDefault = false seems to restore the previously selected state "isDefault", or if there is none, makes the first profile "Default". behavior works for me. But unfortunately after the profile is created and before its state is changed manually in the UI, it reports isDefault = false. Expected: isDefault matches the UI state at all times. //
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This works for me, but note that the synchronization of the new profile is asynchronous after its creation. This is intentional because it's common for extensions to create a profile and then set its properties, like we don't want to cause that to override what the user previously set (especially since making isDefault a 'live' property was a later addition to the API). For me, adding a listener like triggers shortly after its creation
Fascinating! I can't reproduce this bug today.
It seems like there is some inconsistency here
A simple snippet like this surfaces the issue for me: The console is saying And the GUI has run 1 as (Default)
Looks like this is working now:
Code change:
import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { ActiveEditorContext } from 'vs/workbench/common/contextkeys'; import { DiffElementViewModelBase } from 'vs/workbench/contrib/notebook/browser/diff/diffElementViewModel'; <del> import { NOTEBOOK_DIFF_CELL_INPUT, NOTEBOOK_DIFF_CELL_PROPERTY, NOTEBOOK_DIFF_CELL_PROPERTY_EXPANDED } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditorBrowser'; </del> <ins> import { INotebookTextDiffEditor, NOTEBOOK_DIFF_CELL_INPUT, NOTEBOOK_DIFF_CELL_PROPERTY, NOTEBOOK_DIFF_CELL_PROPERTY_EXPANDED } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditorBrowser'; </ins> import { NotebookTextDiffEditor } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditor'; import { NotebookDiffEditorInput } from 'vs/workbench/contrib/notebook/common/notebookDiffEditorInput'; <del> import { openAsTextIcon, renderOutputIcon, revertIcon } from 'vs/workbench/contrib/notebook/browser/notebookIcons'; </del> <ins> import { nextChangeIcon, openAsTextIcon, previousChangeIcon, renderOutputIcon, revertIcon } from 'vs/workbench/contrib/notebook/browser/notebookIcons'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { Registry } from 'vs/platform/registry/common/platform'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions } from 'vs/platform/configuration/common/configurationRegistry'; import { ICommandActionTitle } from 'vs/platform/action/common/action'; import { DEFAULT_EDITOR_ASSOCIATION } from 'vs/workbench/common/editor'; <ins> import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { NOTEBOOK_DIFF_EDITOR_ID } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> // ActiveEditorContext.isEqualTo(SearchEditorConstants.SearchEditorID)

Related discussion:
text: Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.
Code change:
import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { ActiveEditorContext } from 'vs/workbench/common/contextkeys'; import { DiffElementViewModelBase } from 'vs/workbench/contrib/notebook/browser/diff/diffElementViewModel'; <del> import { NOTEBOOK_DIFF_CELL_INPUT, NOTEBOOK_DIFF_CELL_PROPERTY, NOTEBOOK_DIFF_CELL_PROPERTY_EXPANDED } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditorBrowser'; </del> <ins> import { INotebookTextDiffEditor, NOTEBOOK_DIFF_CELL_INPUT, NOTEBOOK_DIFF_CELL_PROPERTY, NOTEBOOK_DIFF_CELL_PROPERTY_EXPANDED } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditorBrowser'; </ins> import { NotebookTextDiffEditor } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditor'; import { NotebookDiffEditorInput } from 'vs/workbench/contrib/notebook/common/notebookDiffEditorInput'; <del> import { openAsTextIcon, renderOutputIcon, revertIcon } from 'vs/workbench/contrib/notebook/browser/notebookIcons'; </del> <ins> import { nextChangeIcon, openAsTextIcon, previousChangeIcon, renderOutputIcon, revertIcon } from 'vs/workbench/contrib/notebook/browser/notebookIcons'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { Registry } from 'vs/platform/registry/common/platform'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions } from 'vs/platform/configuration/common/configurationRegistry'; import { ICommandActionTitle } from 'vs/platform/action/common/action'; import { DEFAULT_EDITOR_ASSOCIATION } from 'vs/workbench/common/editor'; <ins> import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { NOTEBOOK_DIFF_EDITOR_ID } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> // ActiveEditorContext.isEqualTo(SearchEditorConstants.SearchEditorID)

Related discussion:
text: Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" alt="image" src="https://user-"
Code change:
export class ContentHoverWidget extends ResizableContentWidget { public static ID = 'editor.contrib.resizableContentHoverWidget'; <ins> private static _lastDimensions: dom.Dimension = new dom.Dimension(0, 0); </ins> private _visibleData: ContentHoverVisibleData | undefined; private _positionPreference: ContentWidgetPositionPreference | undefined;

Related discussion:
text: Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.
Code change:
import { InputFocusedContext } from 'vs/platform/workbench/common/contextkeys'; import { ServicesAccessor } from 'vs/editor/browser/editorExtensions'; import { PanelFocusContext } from 'vs/workbench/browser/parts/panel/panelPart'; <ins> import { CommandsRegistry } from 'vs/platform/commands/common/commands'; import { onUnexpectedError } from 'vs/base/common/errors'; </ins> export const ADD_CONFIGURATION_ID = 'debug.addConfiguration'; export const TOGGLE_INLINE_BREAKPOINT_ID = 'editor.debug.action.toggleInlineBreakpoint'; export function registerCommands(): void { <ins> CommandsRegistry.registerCommand({ id: 'debug.startFromConfig', handler: (accessor, config: IConfig) => { const debugService = accessor.get(IDebugService); debugService.startDebugging(undefined, config).then(undefined, onUnexpectedError); } }); </ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ id: 'debug.toggleBreakpoint', weight: KeybindingWeight.WorkbenchContrib + 5,

Related discussion:
text: Somehow I missed the change in the and only now found it out. What I do not udnerstand is why we need all this code? I think this handler should be removed and the action should be called like it was done previously. Code pointer: It would be great if we could tackle this in December. Thanks
The reason for this code change was that creates a handler for command that passes no arguments to the action: So instead I used with a handler that would forward the argument. It looks like there are other debug commands registered in this way in , so I think moving the code for startDebug there makes sense. The handlers there are shorter and less generic, I'll see if rewriting the startDebug one that way causes any issues
what you need is calling the start debug with a configuration, and I believe we already have a way for doing this. can you please provide a pointer to where you are already calling start debug with a configuration. are you calling start debug from the main side or where from exactly? I can also look into this. You can just let me know how to verify that I did not break your scenario.
The extension API's implementation passes a debug configuration to the debug service's startDebugging here:
I'm trying to start debugging from the process explorer. Since it's a separate browser window, it doesn't have access to the debug workbench service, and it's also not an extension, so it can't leverage the extension API for starting debugging. Currently, the process explorer window sends an IPC message back to the issue service in the main process. This then sends an IPC message to the main renderer process to run the debug start command: The path is also used by the native menu to trigger commands from the main process.
ok got it. So the best way it seems is to what you have done going via the action. Can you try to clean up the handler. And if that does not work I can look into an alternative solution.
Sure, I'll work on cleaning up the handler today
Code change:
properties: { type: { type: 'string', <del> description: nls.localize('runTask.type', "The contributed task type"), enum: Array.from(this._providerTypes.values()).map(provider => provider) </del> <ins> description: nls.localize('runTask.type', "The contributed task type") </ins> }, taskName: { type: 'string', <del> description: nls.localize('runTask.taskName', "The task's label or a term to filter by"), enum: await this.tasks().then((tasks) => tasks.map(t => t._label)) </del> <ins> description: nls.localize('runTask.taskName', "The task's label or a term to filter by") </ins> } } }

Related discussion:
text: deferring from as I spent more than an hour on it
This is a little different to how we do it in the terminal because the command palette entry: is registered separately to the command: also doesn't show up at all as a command anymore: Insiders: ! Stable: !
Commenting out the schema fixes the problem for runTask and the commands below.
here needs workspace trust:
removed because the change was reverted so it doesn't work
Code change:
private currentMediaComponent: string | undefined = undefined; private currentMediaType: string | undefined = undefined; <del> private async buildMediaComponent(stepId: string) { </del> <ins> private async buildMediaComponent(stepId: string, forceRebuild: boolean = false) { </ins> if (!this.currentWalkthrough) { throw Error('no walkthrough selected'); } const stepToExpand = assertIsDefined(this.currentWalkthrough.steps.find(step => step.id === stepId)); <del> if (this.currentMediaComponent === stepId) { return; } </del> <ins> if (!forceRebuild && this.currentMediaComponent === stepId) { return; } </ins> this.currentMediaComponent = stepId; this.stepDisposables.clear();

Related discussion:
text: Type: <bBug</bThank you for all the improvements to walkthroughs in the latest release, however I noticed that the following issue started popping up after the changes to "save" your place in a walkthrough when changing tabs. When you have a walkthrough open: to a different tab in the same editor window back to the walkthrough that the media on the right side of the walkthrough is no longer present steps 1. and 2., note that the media has reappeared. If you repeat steps 1. and 2. once more, the media will dissapear again. This process can be repeated any number of times to "toggle" the media's visibility. Jumping between steps will also cause the media to reappear.
Code change:
private currentMediaComponent: string | undefined = undefined; private currentMediaType: string | undefined = undefined; <del> private async buildMediaComponent(stepId: string) { </del> <ins> private async buildMediaComponent(stepId: string, forceRebuild: boolean = false) { </ins> if (!this.currentWalkthrough) { throw Error('no walkthrough selected'); } const stepToExpand = assertIsDefined(this.currentWalkthrough.steps.find(step => step.id === stepId)); <del> if (this.currentMediaComponent === stepId) { return; } </del> <ins> if (!forceRebuild && this.currentMediaComponent === stepId) { return; } </ins> this.currentMediaComponent = stepId; this.stepDisposables.clear();

Related discussion:
text: Screen recording: VS Code version: Code 1.87.0 (Universal) (, 2024-02-27T23:42:56.944Z) OS version: Darwin arm64 22.6.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (34)</summaryExtensionVersion ------ vscode-markdownlint0.54.0 vscode-eslint2.4.4 gitlens14.8.2 EditorConfig0.16.4 prettier-vscode10.1.0 go0.41.1 vscode-drawio1.6.6 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.3 jupyter2024.2.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 makefile-tools0.8.22 vsliveshare1.0.5918 ansible2.13.148 java1.28.1 vscode-yaml1.14.0 sonarlint-vscode4.3.0 code-spell-checker3.0.1 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-java-debug0.56.2 vscode-java-dependency0.23.5 vscode-java-pack0.25.15 vscode-java-test0.40.1 vscode-maven0.44.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Code change:
), })); <del> this._register(Event.runAndSubscribe(this._editors.modified.onDidChangeCursorPosition, (e) => { if (e?.reason === CursorChangeReason.Explicit) { const diff = this._diffModel.get()?.diff.get()?.mappings.find(m => m.lineRangeMapping.modified.contains(e.position.lineNumber)); if (diff?.lineRangeMapping.modified.isEmpty) { this._accessibilitySignalService.playSignal(AccessibilitySignal.diffLineDeleted, { source: 'diffEditor.cursorPositionChanged' }); } else if (diff?.lineRangeMapping.original.isEmpty) { this._accessibilitySignalService.playSignal(AccessibilitySignal.diffLineInserted, { source: 'diffEditor.cursorPositionChanged' }); } else if (diff) { this._accessibilitySignalService.playSignal(AccessibilitySignal.diffLineModified, { source: 'diffEditor.cursorPositionChanged' }); } } })); </del> <ins> this._register(Event.runAndSubscribe(this._editors.modified.onDidChangeCursorPosition, e => this._handleCursorPositionChange(e, true))); this._register(Event.runAndSubscribe(this._editors.original.onDidChangeCursorPosition, e => this._handleCursorPositionChange(e, false))); </ins> const isInitializingDiff = this._diffModel.map(this, (m, reader) => { /** @isInitializingDiff isDiffUpToDate */

Related discussion:
text: mentioned that the diff editor experience is a little confusing because we don't explicitly state that the current editor is the modified one vs the original editor. AFAICT, there's also no way to jump between the original and modified ones. Is this correct? & I'd appreciate your thoughts here. Edit: action items: [ ] add info in help dialog about switch sides command [ ] get accessibility signals to work in original editor
There is the Diff Editor: Switch Sides command that moves focus to the other side. Maybe the wording could be improved. So not sure what needs to be done here? Feels like similar to the other issue you created about missing clarity in announcements on original vs modified.
Yes, I was unaware of that command. We should include it in the diff editor help dialog and include a default keybinding for when in screen reader mode as that's definitely something users would want to do IMO.
pointed out this should maybe be a tab stop if possible
I have the following keybinding, but there was no noticeable change (at least to from a screen reader user's standpoint) after switching into the other side. :
could you tell there was a focus change at all? Is there also no difference if you run the command vs use the keybinding?
Audio cues do not work when I'm navigating in the original editor. !
Code change:
detachInstance() { if (!this._isShuttingDown) { this._terminalInstance?.detachFromElement(); <ins> this._terminalInstance?.setParentContextKeyService(this._contextKeyService); </ins> this._isDetached = true; } }

Related discussion:
text: Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.
Code change:
detachInstance() { if (!this._isShuttingDown) { this._terminalInstance?.detachFromElement(); <ins> this._terminalInstance?.setParentContextKeyService(this._contextKeyService); </ins> this._isDetached = true; } }

Related discussion:
text: I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- 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!
/verified, but while confirming the fix I noticed more issues with these context keys