jiebi/CodeConvo huggingface dataset:
Change:
} /* Window Title Menu */ <ins> .monaco-workbench .part.titlebar>.titlebar-container>.window-title.title-menu { z-index: 3000; -webkit-app-region: no-drag; } </ins> .monaco-workbench .part.titlebar>.titlebar-container>.window-title.title-menu .action-item.quickopen { color: var(--vscode-input-foreground); border: 1px solid var(--vscode-dropdown-border);

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/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: Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-11T05:17:12.474Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: here are my settings: The new titleMenu shows up, but it is not clickable !
Change:
} try { <ins> this._deltaDecorationCallCnt++; if (this._deltaDecorationCallCnt > 1) { console.warn(`Invoking deltaDecorations recursively could lead to leaking decorations.`); onUnexpectedError(new Error(`Invoking deltaDecorations recursively could lead to leaking decorations.`)); } </ins> this._onDidChangeDecorations.beginDeferredEmit(); return this._deltaDecorationsImpl(ownerId, oldDecorations, newDecorations); } finally { this._onDidChangeDecorations.endDeferredEmit(); <ins> this._deltaDecorationCallCnt--; </ins> } }

Discussion:
VS Code: 1.67.0 (, 2022-05-04T12:06:02.889Z) Since this update (also tested on clean Insiders), if a variable is selected using the "" shortcut ( in my case), the occurrence indicators of it don't clean up when selection is canceled by cursor navigating away from it. Here is how it works with a mouse (correct): ! And with a shortcut (stay forever): ! They won't clean up even if I select a different variable, the indicators are just to the previous ones. They only disappear if I switch editor to a different file and come back.
fyi this is also caused by recursing i.e.
Would you like to release a patch? This bug is so annoying!!!
Change:
suite(`Link "${baseLink}"`, () => { for (let i = 0; i < supportedLinkFormats.length; i++) { const linkFormat = supportedLinkFormats[i]; <del> test(`Format: ${linkFormat.urlFormat}`, async () => { const formattedLink = format(linkFormat.urlFormat, baseLink, linkFormat.line, linkFormat.column); </del> <ins> const formattedLink = format(linkFormat.urlFormat, baseLink, linkFormat.line, linkFormat.column); test(`should detect in "${formattedLink}"`, async () => { </ins> await assertLink(TerminalBuiltinLinkType.LocalFile, formattedLink, [{ text: formattedLink, range: [[1, 1], [formattedLink.length, 1]] }]); await assertLink(TerminalBuiltinLinkType.LocalFile, ` ${formattedLink} `, [{ text: formattedLink, range: [[2, 1], [formattedLink.length + 1, 1]] }]); await assertLink(TerminalBuiltinLinkType.LocalFile, `(${formattedLink})`, [{ text: formattedLink, range: [[2, 1], [formattedLink.length + 1, 1]] }]);

Discussion:
These flakes are a bit odd, not sure what could cause them and the failures seem a bit all over the place
I some logs that will help with debugging future failures. Closing in the meantime until a new one pops up.
Change:
[['c:/ignore', 'd:a/bc/d', 'e.exe'], 'd:e.exe'], [['c:/ignore', 'c:/some/file'], 'c:somefile'], [['d:/ignore', 'd:some/dir//'], 'd:ignoresomedir'], <del> [['.'], process.cwd()], </del> [['//server/share', '..', 'relative'], 'serversharerelative'], [['c:/', '//'], 'c:'], [['c:/', '//dir'], 'c:dir'],

Discussion:
We will ship Electron with to stable soon so we should also look into bringing our copy of library to the same version. Checking for the diff, it seems to be a few commits after and up until //cc
Hm, the first change is already pretty bad for us: Because it seems to depend on a new thing which is maybe defined globally and probably optimised / cached / snapshotted. Maybe we should rather look out for actual bug fixes and focus on those... Changes: I think only the 2 fix commits stand out from the others
I assume you skipped over right?
Reopening given unit test failures, I had to revert the change for now.
yes I skipped the primordials. I didn't dig into why they do this, but it seemed easy enough to just call the string functions instead. As for the test failures, new PR
Primordials are only meant for Nodejs internal code usage, external users should just replace them with corresponding JavaScript builtins. You can read more about why Nodejs does it
Change:
//#region File operations <del> async create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { </del> <ins> create(resource: URI, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { return this.doCreateFileOrFolder(resource, true, contents, options); } createFolder(resource: URI, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { return this.doCreateFileOrFolder(resource, false); } async doCreateFileOrFolder(resource: URI, isFile: boolean, contents?: VSBuffer | VSBufferReadable | VSBufferReadableStream, options?: { overwrite?: boolean }): Promise<IFileStatWithMetadata> { </ins> // validate create operation before starting <del> const validateCreate = await this.fileService.canCreateFile(resource, options); if (validateCreate instanceof Error) { throw validateCreate; </del> <ins> if (isFile) { const validateCreate = await this.fileService.canCreateFile(resource, options); if (validateCreate instanceof Error) { throw validateCreate; } </ins> } // file operation participant

Discussion:
It does fire for folder on move and delete. According to the reason lies here: The code goes directly to the file service. Since we correctly report move and delete for folders I think we should report create as well.
Some background: I want to adopt this in LSP but specing that this only works for move and delete of folders sounds a little silly. So I want to make sure that there is either a very compelling reason or there is some ack. that we will fix it in the future.
We currently have no related method such as for folders that the explorer could use here: If we support this, I guess one question in terms of API breakage is wether it is fine to let and emit events for folders too while they currently only emit for files. If we think this is fine, then I think this would be a relatively simple change to make.
I don't consider that breakage, it's a bug fix esp. given that move and delete already fire events for both
Verification: write an extension that registers to and and verify you see both events when you right click into the explorer and create a new folder.
Thanks for fixing!
Change:
// Prevent workbench from scrolling #55456 this._register(addDisposableListener(this.container, EventType.SCROLL, () => this.container.scrollTop = 0)); <ins> // Prevent native context menus in web #73781 if (isWeb) { this._register(addDisposableListener(this.container, EventType.CONTEXT_MENU, (e) => EventHelper.stop(e, true))); } </ins> // Menubar visibility changes if ((isWindows || isLinux) && getTitleBarStyle(this.configurationService, this.environmentService) === 'custom') { this._register(this.titleService.onMenubarVisibilityChange(visible => this.onMenubarToggled(visible)));

Discussion:
Steps: right click into explorer root node you see native and custom menu ! Looks like the new tree is not preventing default and bubbling of event like the old tree did?
Change:
} const edits: vscode.SnippetTextEdit[] = []; <del> let placeHolderValue = ranges.length; </del> let insertedLinkCount = 0; let insertedImageCount = 0; let insertedAudioVideoCount = 0; <del> for (const range of ranges) { </del> <ins> // Use 1 for all empty ranges but give non-empty range unique indices starting after 1 let placeHolderStartIndex = 1 + entries.length; // Sort ranges by start position const orderedRanges = [...ranges].sort((a, b) => a.start.compareTo(b.start)); const allRangesAreEmpty = orderedRanges.every(range => range.isEmpty); for (const range of orderedRanges) { </ins> const snippet = createUriListSnippet(document.uri, entries, { <del> placeholderText: !range.isEmpty ? document.getText(range) : undefined, placeholderStartIndex: placeHolderValue, </del> <ins> placeholderText: range.isEmpty ? undefined : document.getText(range), placeholderStartIndex: allRangesAreEmpty ? 1 : placeHolderStartIndex, </ins> }); if (!snippet) { continue;

Discussion:
Testing a link in your clipboard multiple cursors in a Markdown file. Do not have anything selected. . Notice how the [Title] placeholder only gets selected at the primary cursor I would prefer if we would select all "Title" for each cursor. That way it would be more convenient for the user to change all the "Title" placeholders at once.
Because the user would have selected multiple cursors, it would be expected that each cursor has different text which is why all the placeholders are not selected. It might make sense to make it that if nothing is selected, then all the placeholders could be selected at once, however the differing functionalities might get confusing.
Hmm for multi cursor you will be pasting the same link multiple times. What scenario do you think is more common, that users would want different titles for the same link, or the same title for that link?
I tried this doing this all the time but found it strange. Here's what I found felt more natural: If the user has explicitly selected text with the cursor, make sure to preserve that. This means that each selection gets its own placeholder Otherwise give empty selections the same placeholder index. That way you can update empty selections all at once If there's a mix of the empty and non-empty selections (a difficult state to get into), fallback to using unique placeholders for each This makes the behavior less consistent but feels more correct to me
Change:
if (typeof hint.label === 'string') { result.label = hint.label; } else { <del> result.label = hint.label.map(part => { const result: languages.InlayHintLabelPart = { label: part.value }; result.tooltip = typeConvert.MarkdownString.fromStrict(part.tooltip); </del> <ins> const parts: languages.InlayHintLabelPart[] = []; result.label = parts; for (const part of hint.label) { if (!part.value) { console.warn('INVALID inlay hint, empty label part', this._extension.identifier.value); continue; } const part2: languages.InlayHintLabelPart = { label: part.value, tooltip: typeConvert.MarkdownString.fromStrict(part.tooltip) }; </ins> if (Location.isLocation(part.location)) { <del> result.location = typeConvert.location.from(part.location); </del> <ins> part2.location = typeConvert.location.from(part.location); </ins> } if (part.command) { <del> result.command = this._commands.toInternal(part.command, disposables); </del> <ins> part2.command = this._commands.toInternal(part.command, disposables); </ins> } <del> return result; }); </del> <ins> parts.push(part2); } </ins> } return result; }

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?: 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.75.0 OS Version: win 11 Steps to Reproduce: -analyzer inlay hints' padding look weird. The inlay type hint for has no round padding on right side, while the type hint looks normal. !
I think it might have something to do with type hint being ctrl-clickable. The non-clickable types like is fine. Also, for other languages that does not support ctrl-click on inlay hints, the rendering is also fine.
Any update for this issue?
I can reproduce, but only with Rust Analyzer. This issue is that it returns a label part that's empty. When rending we add the padding/border to that element but because its empty, it never gets rendered <img width="560" alt="Screenshot 2023-12-04 at 12 54 56" src=""
Change:
private _onDidChangeHeight = this._register(new Emitter<number>()); readonly onDidChangeHeight = this._onDidChangeHeight.event; <ins> private readonly _onDidChangeContentHeight = new Emitter<void>(); readonly onDidChangeContentHeight: Event<void> = this._onDidChangeContentHeight.event; </ins> private contribs: IChatWidgetContrib[] = []; private tree!: WorkbenchObjectTree<ChatTreeItem>;

Discussion:
Repro: in inline chat: !
Oh it's a scroll shadow: !
We closed this issue because it is a question about using VS Code rather than an issue or feature request. Please search for help on , where the community has already answered thousands of similar questions. You may find their helpful if your question has not already been asked. See also our . Happy Coding!
I blame it your theme. Inline chat isn't doing anything special here, tho we might wanna tweak the min size
The problem here is that the height of the chat widget inside the inline chat isn't correct and doesn't seem to be updated when the answer is streamed in. There is much more than 40% room available so it should show the full response. Also this is Dark Modern; the theme is fine it's the size: !
That's surprising. Notice how it works here until it reaches the max zone height
Must be related to the code block being replied with. But whatever I do I cannot get it to reply like that...
Ok, I can repro in a TS file with . Looks like the tree reports the wrong content height. Overall we measure 94px (for the input and tree) when in fact only the tree is 107px <img width="1272" alt="Screenshot 2024-03-22 at 16 37 16" src=""
Is editor rendering somehow async and should I ask for content height at some later point?
Change:
}, { "command": "git.revealFileInOS.linux", <del> "when": "scmProvider == git && scmResourceGroup == merge && resourceScheme == file && isLinux", </del> <ins> "when": "scmProvider == git && scmResourceGroup == merge && remoteName == '' && isLinux", </ins> "group": "2_view@2" }, { "command": "git.revealFileInOS.mac", <del> "when": "scmProvider == git && scmResourceGroup == merge && resourceScheme == file && isMac", </del> <ins> "when": "scmProvider == git && scmResourceGroup == merge && remoteName == '' && isMac", </ins> "group": "2_view@2" }, { "command": "git.revealFileInOS.windows", <del> "when": "scmProvider == git && scmResourceGroup == merge && resourceScheme == file && isWindows", </del> <ins> "when": "scmProvider == git && scmResourceGroup == merge && remoteName == '' && isWindows", </ins> "group": "2_view@2" }, {

Discussion:
Testing Open a git repository from WSL Modify files and save Go to SCM view, right click on a change Click on "Reveal in File Explorer" Nothing happens
The latest Insiders has been updated, so that the new menu item does not appear when connected to a remote.
<img width="307" alt="image" src="https://user-"Reveal in File Explorer is gone . However Open Containing Folder is there and it does do anything either.
Change:
export interface IWaitUntil { <ins> token: CancellationToken; </ins> waitUntil(thenable: Promise<unknown>): void; } <ins> export type IWaitUntilData<T> = Omit<Omit<T, 'waitUntil'>, 'token'>; </ins> export class AsyncEmitter<T extends IWaitUntil> extends Emitter<T> { <del> private _asyncDeliveryQueue?: LinkedList<[Listener<T>, Omit<T, 'waitUntil'>]>; </del> <ins> private _asyncDeliveryQueue?: LinkedList<[Listener<T>, IWaitUntilData<T>]>; </ins> <del> async fireAsync(data: Omit<T, 'waitUntil'>, token: CancellationToken, promiseJoin?: (p: Promise<unknown>, listener: Function) => Promise<unknown>): Promise<void> { </del> <ins> async fireAsync(data: IWaitUntilData<T>, token: CancellationToken, promiseJoin?: (p: Promise<unknown>, listener: Function) => Promise<unknown>): Promise<void> { </ins> if (!this._listeners) { return; }

Discussion:
continues Timeout and user-cancellation applies when calling -events. However, we don't expose that in the API and silently stop async-event delivery and ignore results. We could let extension know via
For some big repo, it is possible for LS to parse more then hundreds files (which takes long time), right now, this can't be cancelled since we (LS) don't get any cancellation token (hence, no cancellation request). vscode side acts like it is cancelled, but only front end (vscode) is cancelled, all the backends (LSP and LS) that are actually doing the work are not cancelled. so even if vscode code send new requests (since vscode side is cancelled), LSP/LS won't be able to respond (not all LS is designed to process concurrent requests especially requests that have potential to change LS states). so only front end cancellation won't help much overall experiences.
fyi - this is now a thing and ready for LSP adoption
Neat, thanks
I verified that the token is available on the events, but it wasn't clear to me how to cause a user cancellation of the save/rename/delete. Can this only be done if there's slow file system provider?
You can call of the event with a promise that never or slowly resolves. Eventually the UI shows a progress notification which allows to cancel. That cancel will propagate to the extension.
I have now also verified that the token properly reflects the cancel status.
Thanks!
Change:
declare module 'xterm' { type LinkMatcherHandler = (event: MouseEvent, uri: string) => boolean | void; <del> class Terminal { </del> <ins> export class Terminal { </ins> cols: number; rows: number; ydisp: number;

Discussion:
Upstream issue: Please verify this on Linux by opening tmux in mouse mode and ensuring regular mouse selection triggers "tmux selection" and shift+mouse selection triggers the regular terminal selection.
I thought I verified this last month?
this was Mac only last month, needs verification on Linux.

Scrolling within the integrated terminal doesn't scroll curses interfaces such as , , , etc. <!-- Use Help Report Issues to prefill these. --- VSCode Version: Version 1.15.0 OS Version: Arch Linux Shell: ZSH (oh-my-zsh) the integrated terminal ( ``) a curses style pager interface (e.g. , , , ) the mouse scrollwheel to try and scroll the pager happens, using keyboard commands to scroll works fine (, , , , arrow keys, etc) a seperate terminal (e.g. or ) step 2 & 3 above as expected; pager scrolls <!-- Launch with to check. --Reproduces without extensions: Yes
This should be fixed in the next version. Note that this only applies to applications that launch the alt buffer however, so it does not apply to . Upstream issue:
Sounds like the upstream issue might be a different one to this. It appears to be about the alternative buffer being rendered twice after a scroll. This is about passing scroll events to pager style programs, such as less and git log.
The reason scroll isn't making it to the terminal app is because the scrollbar is grabbing the event and not passing it to the terminal. When there is no scrollback it gets sent to the terminal correctly.
It works in tmux fine now but not vim yet.
This has been working for a few versions now
Change:
// perform a html format and apply changes to a new document const htmlMode = languageModes.getMode('html')!; const htmlEdits = await htmlMode.format!(document, formatRange, formattingOptions, settings); <del> const htmlFormattedContent = TextDocument.applyEdits(document, htmlEdits); </del> <ins> let htmlFormattedContent = TextDocument.applyEdits(document, htmlEdits); if (formattingOptions.insertFinalNewline && endOffset === content.length && !htmlFormattedContent.endsWith('n')) { htmlFormattedContent = htmlFormattedContent + 'n'; htmlEdits.push(TextEdit.insert(endPos, 'n')); } </ins> const newDocument = TextDocument.create(document.uri + '.tmp', document.languageId, document.version, htmlFormattedContent); try { // run embedded formatters on html formatted content: - formatters see correct initial indent

Discussion:
Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.0 OS Version: Windows 10 Enterprise 21H2 .2728 Steps to Reproduce: to a HTML file with a -block with some CSS rules a new line getting to the end of the file (correct) and to the end of the -block before the closing tag (issue!)
I can not reproduce ! The option dos only impact the last new line. The new line inserted before comes from the setting Can you provide an example. Make sure you are using the built-in HTML formatter.
You have to use a -block. It will not happen with any other HTML-Element.
Change:
} }); <ins> this.addEventListener('issue-title', 'input', _ => { const titleElement = this.getElementById('issue-title') as HTMLInputElement; if (titleElement) { const title = titleElement.value; this.issueReporterModel.update({ issueTitle: title }); } }); </ins> this.addEventListener('issue-title', 'input', (e: Event) => { const title = (<HTMLInputElement>e.target).value; const lengthValidationMessage = this.getElementById('issue-title-length-validation-error');

Discussion:
Testing to open the issue reporter for an extension issue reporter open, return to the main window step 1 for another extension =issue reporter opens but doesn't update the issue reporter input fields.
Change:
await mkdirp(parentPath); try { <del> await this.exec(parentPath, ['clone', url, folderPath], { cancellationToken }); </del> <ins> await this.exec(parentPath, ['clone', url.includes(' ') ? encodeURI(url) : url, folderPath], { cancellationToken }); </ins> } catch (err) { if (err.stderr) { err.stderr = err.stderr.replace(/^Cloning.+$/m, '').trim();

Discussion:
Issue Type: <bBug</bCreate a repo with a name that contains one or more spaces. Put something in it eg a and then attempt to clone it via VS Code. VS Code fails to URL encode the URL, and fails to quote the folder name that it creates. I copied the generated git command and did those things to it and then it worked as expected. VS Code version: Code 1.28.0 (, 2018-10-05T14:58:53.203Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 aurelia1.0.3 xml2.3.2 gitlens8.5.6 vscode-test-explorer2.0.9 reg0.0.2 mssql1.4.0 csharp1.16.2 PowerShell1.9.0 vsliveshare0.3.735 team1.136.0 </details<!-- generated by issue reporter --
The reason I removed the Windows from the bug title is I suspect the problem will take much the same form with the same solution on all platforms.
Are there any news on this? I am hitting this issue quite often
Change:
id: 'workbench.editSessions.actions.showEditSessions', title: { value: localize('show edit session', "Show Edit Sessions"), original: 'Show Edit Sessions' }, category: EDIT_SESSION_SYNC_CATEGORY, <del> f1: true, precondition: EDIT_SESSIONS_SIGNED_IN </del> <ins> f1: true </ins> }); }

Discussion:
Testing I would expect that this action always appears in the command palette. Today, it only appears after running or first.