jiebi/CodeConvo huggingface dataset:
Change:
Testing Unexpected behavior here: It seems to be scrolling to the right spot but the peek view is partially out of view: ! The file Code - OSS @ : Version: 1.71.0 Commit: Unknown Date: Unknown Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No
This can happen when a symbol has multiple definition locations. In that case we use peek to show all definitions and we need to make sure that revealing works nicer.
This seems like it's still present on today's Insiders https://user- If it helps to test, this is the file I was using:
Hi Connor, thanks for your bug. This should be solved with the PR: that was created today. The new behavior is: !
The cursor position is still wrong when I try verify on the same file: !
Nvm, tested the wrong version due to delayed insiders today

Discussion:
private _hoverOnLine: number; private _hoverOnColumn: number; private _stickyRangeProjectedOnEditor: IRange | null; <ins> private _candidateDefinitionsLength: number; </ins> constructor( private readonly _editor: ICodeEditor,

this._hoverOnLine = -1; this._hoverOnColumn = -1; this._stickyRangeProjectedOnEditor = null; <ins> this._candidateDefinitionsLength = -1; </ins> this._lineHeight = this._editor.getOption(EditorOption.lineHeight); this._register(this._editor.onDidChangeConfiguration(e => { if (e.hasChanged(EditorOption.lineHeight)) {

return; } if (candidateDefinitions.length !== 0) { <ins> this._candidateDefinitionsLength = candidateDefinitions.length; </ins> const childHTML: HTMLElement = targetMouseEvent.element; if (currentHTMLChild !== childHTML) { sessionStore.clear();

sessionStore.clear(); })); linkGestureStore.add(gesture.onExecute(async e => { <del> if (this._hoverOnLine !== -1) { if (e.hasTriggerModifier) { // Control click this._instaService.invokeFunction(goToDefinitionWithLocation, e, this._editor as IActiveCodeEditor, { uri: this._editor.getModel()!.uri, range: this._stickyRangeProjectedOnEditor } as Location); } else { // Normal click </del> <ins> if ((e.target as unknown as CustomMouseEvent).detail !== this.getId()) { return; } if (e.hasTriggerModifier) { // Control click if (this._candidateDefinitionsLength > 1) { </ins> this._editor.revealPosition({ lineNumber: this._hoverOnLine, column: 1 }); } <ins> this._instaService.invokeFunction(goToDefinitionWithLocation, e, this._editor as IActiveCodeEditor, { uri: this._editor.getModel()!.uri, range: this._stickyRangeProjectedOnEditor } as Location); } else { // Normal click this._editor.revealPosition({ lineNumber: this._hoverOnLine, column: 1 }); </ins> } })); return linkGestureStore; }
Change:
!
I heard of this before, but unfortunately, I cannot reproduce this on windows.
I also cannot repro on mac. That to me looks like a custom checkbox implementation, so it should not be platform dependant. maybe you check how we handle clicks to trigger context menu, if there is a bug it should be there. For example, maybe first stop propagating the event before you trigger the context menu here That might fix it. Since context menu show freezes the renderer process, so it might happen that the click event can not get canceled after that and it results in the unexpected click.
This got obsolete by the transition to code-lens actions.

Discussion:
} if (e.button === /* Right */ 2) { <ins> e.stopPropagation(); e.preventDefault(); </ins> contextMenuService.showContextMenu({ getAnchor: () => checkBox.domNode, getActions: item.getContextMenuActions, }); <del> e.stopPropagation(); e.preventDefault(); </del> } else if (e.button === /* Middle */ 1) { <del> item.toggleBothSides(); </del> e.stopPropagation(); e.preventDefault(); <ins> item.toggleBothSides(); </ins> } }) );
Change:
Diff editor is not accessible unless the user uses the F7 / Shift + F7 experience. We should make this more discoverable to the users. For example the aria label of a diff editor should at the end append "use F7 / shift + F7 to navigate changes" fyi
assigning to you and removing the milestone since this might be a good win and something that is within our reach. Namely the diff editor is not that accessible unless users use the experience to navigate between changes. So we should make this more discoverable by potentially mentioning it in the aria label of the diff editor.
Verify that when you are using a screen reader and enter a diff editor, you're informed about using shift + F7 navigation

Discussion:
const diffRemoveIcon = registerIcon('diff-remove', Codicon.remove, nls.localize('diffRemoveIcon', 'Line decoration for removals in the diff editor.')); const ttPolicy = window.trustedTypes?.createPolicy('diffEditorWidget', { createHTML: value => value }); <ins> const ariaNavigationTip = nls.localize('diff-aria-navigation-tip', ' use Shift + F7 to navigate changes'); </ins> export class DiffEditorWidget extends Disposable implements editorBrowser.IDiffEditor { private static readonly ONE_OVERVIEW_WIDTH = 15;

if (options.originalAriaLabel) { result.ariaLabel = options.originalAriaLabel; } <ins> result.ariaLabel += ariaNavigationTip; </ins> result.readOnly = !this._options.originalEditable; result.dropIntoEditor = { enabled: !result.readOnly }; result.extraEditorClassName = 'original-in-monaco-diff-editor';

if (options.modifiedAriaLabel) { result.ariaLabel = options.modifiedAriaLabel; } <ins> result.ariaLabel += ariaNavigationTip; </ins> result.wordWrapOverride1 = this._options.diffWordWrap; result.revealHorizontalRightPadding = EditorOptions.revealHorizontalRightPadding.defaultValue + DiffEditorWidget.ENTIRE_DIFF_OVERVIEW_WIDTH; result.scrollbar!.verticalHasArrows = false;
Change:
Testing When a command is disabled with "enablement": "false", the icon is no longer displayed. ! Here's the tree view item with the icon !

Discussion:
} .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item>.custom-view-tree-node-item-icon.disabled { <del> opacity: 60%; </del> <ins> opacity: 0.6; </ins> } /* makes spinning icons square */ .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item > .custom-view-tree-node-item-icon.codicon.codicon-modifier-spin {
Change:
Trying to test a repo on vscode-dev (for me, ) some changes in the "Continue Edit Session" and "Reopen in Desktop" repository on desktop VS Code opens, but edit session changes are not applied
Update: I see it's actually in the Edit Sessions view, just not continued automatically by the protocol activation. I can manually resume the edit session once desktop opens and the changes appear.
Ah, do you have configured in settings?
I do not
That will be why--the auto resume behavior requires that setting to be configured in the destination workspace for now, otherwise it would still be a manual step.
Tried this and doesn't work for me, do I need a new version of some extension?
you need to have the pre-releases of and installed in the latest VS Code Insiders. If it doesn't work for you, could you please share the contents of the "Log (Edit Sessions)" output channel?
Yes, on pre-release of both of those extensions (in web and desktop). There's nothing in the output, However there are errors in the console window <details<summaryLogs</summary</details
Hm, those errors are all spurious. Do you have the following version of VS Code: Version: 1.71.0-insider (system setup) Commit: Date: 2022-08-25T13:00:37.808Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Or equivalently do you have the following settings
Yes Yes, <img width="353" alt="Screen Shot 2022-08-26 at 13 58 47" src="https://user-"
Oh--have you run the command on desktop VS Code before? If not, could you try doing that and then checking to see if the following flow works for you? https://user- We probably need some settings sync-ed memento state to communicate that we should ask for auth here.

Discussion:
if (this.environmentService.editSessionId !== undefined) { await this.resumeEditSession(this.environmentService.editSessionId).finally(() => this.environmentService.editSessionId = undefined); <del> } else if (this.configurationService.getValue('workbench.experimental.editSessions.autoResume') === 'onReload' && this.editSessionsStorageService.isSignedIn) { </del> <ins> } else if ( this.configurationService.getValue('workbench.experimental.editSessions.enabled') === true && this.configurationService.getValue('workbench.experimental.editSessions.autoResume') === 'onReload' && this.editSessionsStorageService.isSignedIn ) { </ins> // Attempt to resume edit session based on edit workspace identifier // Note: at this point if the user is not signed into edit sessions, // we don't want them to be prompted to sign in and should just return early

], 'type': 'string', 'tags': ['experimental', 'usesOnlineServices'], <del> 'default': 'off', </del> <ins> 'default': 'onReload', </ins> 'markdownDescription': localize('autoResume', "Controls whether to automatically resume an available edit session for the current workspace."), }, }
Change:
Hello, Normally when you double click the top left of a Window, the application closes. When you double click vscode, the application maximizes. Can VSCode have this capability as well to close? !
We have logic to detect and handle double click in the custom title to restore / maximize the window but we missed to handle this case where on Windows it indeed seems to close the app. For this to work we probably have to detect a click on the icon and then call a different method to close instead of the current behaviour. Code pointers: //cc
Oh interesting, that code only runs on macOS, then I wonder what triggers this
Yes, very interesting. For other Windows apps, the menu appears when you single left click the top window as well. In VSCode when you Single Click the top left, nothing happens (In windows 10, all versions, latest VSCode)
Yeah that is expected, we draw the title custom entirely. We need to implement those native integrations on top. Maybe you report as separate issue.
I think you want this setting
doesn't seem to work anymore; I had it set for ages (along with to "custom"), but recently it doesn't seem to do anything...

Discussion:
this.element = parent; this.rootContainer = append(parent, $('.titlebar-container')); <del> // Draggable region that we can manipulate for #52522 this.dragRegion = prepend(this.rootContainer, $('div.titlebar-drag-region')); </del> // App Icon (Native Windows/Linux and Web) if (!isMacintosh && !isWeb) { this.appIcon = prepend(this.rootContainer, $('a.window-appicon'));

} } <ins> // Draggable region that we can manipulate for #52522 this.dragRegion = prepend(this.rootContainer, $('div.titlebar-drag-region')); </ins> // Menubar: install a custom menu bar depending on configuration // and when not in activity bar if (this.titleBarStyle !== 'native'
Change:
! The highlighting is important to understand which conflict in the bottom view corresponds to which conflicts in result. I think the change of the color of the dashed border is difficult to notice.

Discussion:
} .merge-editor-block:not(.handled):not(.focused) { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </ins> } .merge-editor-block:not(.handled).focused { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledFocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledFocused-border); </ins> } .merge-editor-block.handled:not(.focused) {

.conflict-zone-root { background-color: var(--vscode-mergeEditor-change-background); <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </ins> height: 90%; display: flex; align-items: center;

.focused.conflict-zone .conflict-zone-root { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledFocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledFocused-border); </ins> }
Change:
The sentence sounds to me like the trusted workspace isn't currently trusted rather than the file. Maybe reorganising it to can make it clearer? Source:

Discussion:
localize('addWorkspaceFolderMessage', "Do you trust the authors of the files in this folder?"), [localize('yes', 'Yes'), localize('no', 'No')], { <del> detail: localize('addWorkspaceFolderDetail', "You are adding files to a trusted workspace that are not currently trusted. Do you trust the authors of these new files?"), </del> <ins> detail: localize('addWorkspaceFolderDetail', "You are adding files that are not currently trusted to a trusted workspace. Do you trust the authors of these new files?"), </ins> cancelId: 1, custom: { icon: Codicon.shield } }
Change:
and state that it only takes effect when that setting is enabled I didn't know it had to be enabled - so was confused when it didn't work

Discussion:
'explorer.fileNesting.patterns': { 'type': 'object', scope: ConfigurationScope.RESOURCE, <del> 'markdownDescription': nls.localize('fileNestingPatterns', "Controls nesting of files in the explorer. Each __Item__ represents a parent pattern and may contain a single `*` character that matches any string. Each __Value__ represents a comma separated list of the child patterns that should be shown nested under a given parent. Child patterns may contain several special tokens:n- `${capture}`: Matches the resolved value of the `*` from the parent patternn- `${basename}`: Matches the parent file's basename, the `file` in `file.ts`n- `${extname}`: Matches the parent file's extension, the `ts` in `file.ts`n- `${dirname}`: Matches the parent file's directory name, the `src` in `src/file.ts`n- `*`:  Matches any string, may only be used once per child pattern"), </del> <ins> 'markdownDescription': nls.localize('fileNestingPatterns', "Controls nesting of files in the explorer. {0} must be set for this to take effect. Each __Item__ represents a parent pattern and may contain a single `*` character that matches any string. Each __Value__ represents a comma separated list of the child patterns that should be shown nested under a given parent. Child patterns may contain several special tokens:n- `${capture}`: Matches the resolved value of the `*` from the parent patternn- `${basename}`: Matches the parent file's basename, the `file` in `file.ts`n- `${extname}`: Matches the parent file's extension, the `ts` in `file.ts`n- `${dirname}`: Matches the parent file's directory name, the `src` in `src/file.ts`n- `*`:  Matches any string, may only be used once per child pattern", '`#explorer.fileNesting.enabled#`'), </ins> patternProperties: { '^[^*]**?[^*]*$': { markdownDescription: nls.localize('fileNesting.description', "Each key pattern may contain a single `*` character which will match any string."),
Change:
Testing Is the commit button supposed to be bold for the Commit & Sync option when the button isn't wide enough? !
nice catch!

Discussion:
.scm-view .button-container .monaco-description-button > .monaco-button-label, .scm-view .button-container .monaco-description-button > .monaco-button-description { <ins> font-weight: normal; </ins> font-style: inherit; padding: 4px 0; }
Change:
<!-- 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. --The "Run Selected Text In Active Terminal" function (especially with a key binding) is invaluable for quickly testing snippets in bash scripts. Unfortunately, the input is interpreted by the interactive terminal when tabs are used for indentation: Running this snippet leaves the terminal like this: For most terminals, setting in the or running skips the terminal handling for pasted text (see ). The integrated terminal should use bracketed paste (and set this option) by default. Currently, it can be circumvented by running , but then I would have to enable it manually again before using the terminal interactively.
Addendum: manually pasting the block with Strg+Shift+V works as intended
If we do this we need to be careful of edge cases like

Discussion:
const endOfLinePreference = isWindows ? EndOfLinePreference.LF : EndOfLinePreference.CRLF; text = editor.getModel().getValueInRange(selection, endOfLinePreference); } <del> instance.sendText(text, true); </del> <ins> instance.sendText(text, true, true); </ins> if (instance.target === TerminalLocation.Editor) { await terminalEditorService.revealActiveEditor(); } else {
Change:
This is quite confusing: ! FYI
I believe we can't unify but the "old" merge commands should be disabled for the merge editor
does that mean we can fully hide the commands from the command palette when the merge editor is opened? if so

Discussion:
"category": "%command.category%", "title": "%command.accept.all-current%", "original": "Accept All Current", <del> "command": "merge-conflict.accept.all-current" </del> <ins> "command": "merge-conflict.accept.all-current", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.all-incoming%", "original": "Accept All Incoming", <del> "command": "merge-conflict.accept.all-incoming" </del> <ins> "command": "merge-conflict.accept.all-incoming", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.all-both%", "original": "Accept All Both", <del> "command": "merge-conflict.accept.all-both" </del> <ins> "command": "merge-conflict.accept.all-both", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.current%", "original": "Accept Current", <del> "command": "merge-conflict.accept.current" </del> <ins> "command": "merge-conflict.accept.current", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.incoming%", "original": "Accept Incoming", <del> "command": "merge-conflict.accept.incoming" </del> <ins> "command": "merge-conflict.accept.incoming", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.selection%", "original": "Accept Selection", <del> "command": "merge-conflict.accept.selection" </del> <ins> "command": "merge-conflict.accept.selection", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%", "title": "%command.accept.both%", "original": "Accept Both", <del> "command": "merge-conflict.accept.both" </del> <ins> "command": "merge-conflict.accept.both", "enablement": "!isMergeEditor" </ins> }, { "category": "%command.category%",

"category": "%command.category%", "title": "%command.compare%", "original": "Compare Current Conflict", <del> "command": "merge-conflict.compare" </del> <ins> "command": "merge-conflict.compare", "enablement": "!isMergeEditor" </ins> } ], "menus": {
Change:
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
could you please verify this one? Thank you!
Verified: <img width="171" alt="image" src="https://user-"

Discussion:
if (button.secondaryCommands?.length) { const actions: IAction[] = []; for (let index = 0; index < button.secondaryCommands.length; index++) { <del> for (const command of button.secondaryCommands[index]) { </del> <ins> const commands = button.secondaryCommands[index]; for (const command of commands) { </ins> actions.push(new Action(command.id, command.title, undefined, true, async () => await this.executeCommand(command.id, ...(command.arguments || [])))); } <del> if (index !== button.secondaryCommands.length - 1) { </del> <ins> if (commands.length) { </ins> actions.push(new Separator()); } } <ins> // Remove last separator actions.pop(); </ins> // ButtonWithDropdown this.button = new ButtonWithDropdown(this.container, {
Change:
exposes a race condition in activating edit session identity providers when the workspace folders have scheme , which results in edit sessions failing to be applied in time in remote windows. Verification: in settings , make some changes Working On Create New Codespace you are not prompted to sign into edit sessions, and your edits created in are applied

Discussion:
} private async activateProvider(scheme: string) { <ins> const transformedScheme = scheme === 'vscode-remote' ? 'file' : scheme; </ins> const provider = this._editSessionIdentifierProviders.get(scheme); if (provider) { return provider; } <del> await this._extensionService.activateByEvent(`onEditSession:${scheme}`); </del> <ins> await this._extensionService.activateByEvent(`onEditSession:${transformedScheme}`); </ins> return this._editSessionIdentifierProviders.get(scheme); } }
Change:
https://user-
This issue may be same with When run the command on file which using file nesting, passed multiple file paths.

Discussion:
this.view = contextProvider; } <del> getContext(respectMultiSelection: boolean): ExplorerItem[] { </del> <ins> getContext(respectMultiSelection: boolean, ignoreNestedChildren: boolean = false): ExplorerItem[] { </ins> if (!this.view) { return []; }

const items = new Set<ExplorerItem>(this.view.getContext(respectMultiSelection)); items.forEach(item => { try { <del> if (respectMultiSelection && this.view?.isItemCollapsed(item) && item.nestedChildren) { </del> <ins> if (respectMultiSelection && !ignoreNestedChildren && this.view?.isItemCollapsed(item) && item.nestedChildren) { </ins> for (const child of item.nestedChildren) { items.add(child); }

readonly roots: ExplorerItem[]; readonly sortOrderConfiguration: ISortOrderConfiguration; <del> getContext(respectMultiSelection: boolean): ExplorerItem[]; </del> <ins> getContext(respectMultiSelection: boolean, ignoreNestedChildren?: boolean): ExplorerItem[]; </ins> hasViewFocus(): boolean; setEditable(stat: ExplorerItem, data: IEditableData | null): Promise<void>; getEditable(): { stat: ExplorerItem; data: IEditableData } | undefined;

// Explorer if (list instanceof AsyncDataTree && list.getFocus().every(item => item instanceof ExplorerItem)) { // Explorer <del> const context = explorerService.getContext(true); </del> <ins> const context = explorerService.getContext(true, true); </ins> if (context.length) { return context.map(c => c.resource); }
Change:
https://user- Expect: <img width="1440" alt="Snipaste2022-08-2605-17-23" src="https://user-"Actual: <img width="1440" alt="Snipaste2022-08-2605-17-04" src="https://user-"
Yes, this was probably not a good change from me in

Discussion:
if (currentWindowsState.lastPluginDevelopmentHostWindow.uiState.mode === WindowMode.Fullscreen) { if (displaysWithFullScreenWindow.has(currentWindowsState.lastPluginDevelopmentHostWindow.uiState.display)) { if (isMacintosh && !extensionHostWindow.win?.isSimpleFullScreen()) { <del> currentWindowsState.lastPluginDevelopmentHostWindow.uiState.mode = WindowMode.Maximized; </del> <ins> currentWindowsState.lastPluginDevelopmentHostWindow.uiState.mode = WindowMode.Normal; </ins> } } else { displaysWithFullScreenWindow.add(currentWindowsState.lastPluginDevelopmentHostWindow.uiState.display);

if (windowState.uiState.mode === WindowMode.Fullscreen) { if (displaysWithFullScreenWindow.has(windowState.uiState.display)) { if (isMacintosh && windowState.windowId !== currentWindowsState.lastActiveWindow?.windowId && !window.win?.isSimpleFullScreen()) { <del> windowState.uiState.mode = WindowMode.Maximized; </del> <ins> windowState.uiState.mode = WindowMode.Normal; </ins> } } else { displaysWithFullScreenWindow.add(windowState.uiState.display);

} if (!allowFullscreen) { <del> state.mode = WindowMode.Maximized; </del> <ins> state.mode = WindowMode.Normal; </ins> } }