jiebi/CodeConvo huggingface dataset:
Change:
Type: <bBug</bAfter recently I've updated to latest Insiders, nothing works anymore. I tried resetting from scratch, disabling all extensions and removing all custom settings, but nothing works. I can't even enable settings sync. The following results are form basically a brand new insider version (installed using ) <details<summaryWindow logs </summary</details<details<summarySettings sync logs</summary</detailsVS Code version: Code - Insiders 1.72.0-insider (, 2022-09-30T10:53:16.316Z) 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 --PS: there's a typo in the log text outisde instead of outside Steps to reproduce: .
Thanks for creating the issue, please set the following setting until this issue is resolved.
Thanks for the answer. I did it in User settings, but I'm still experiencing the same problem :(
Hello I'm on the latest insider, but I'm still experiencing the same problem:
I am not familiar with how scoop maintains the symlink but from the error it looks like you are still using an older version of the runtime. Can you try uninstalling the insiders and try again. Thanks!
Uninstalling / reinstalling fixed the problems. Thanks

Discussion:
disturl "https://electronjs.org/headers" <del> target "19.0.17" </del> <ins> target "19.1.3" </ins> runtime "electron" build_from_source "true"

"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "0e6da36264d52656d5cd36a4c15937a6a6ca778e" </del> <ins> "commitHash": "83077e9b97c55cd4f9f641530442bcfd1c2ab949" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.17" </del> <ins> "version": "19.1.3" </ins> }, { "component": {

"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.7.2", <del> "electron": "19.0.17", </del> <ins> "electron": "19.1.3", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.17: version "19.0.17" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.17.tgz#850d806e88b1ef141b88b491dc41661778691c27" integrity sha512-3Offu61K+d19EZIc76MhKRsSCqfe3jDiqtD0p8jXr6p/TW7+7/jOQp407ZaZu0nQN6/xDIEi2sP4XQBom6GjTQ== </del> <ins> electron@19.1.3: version "19.1.3" resolved "https://registry.yarnpkg.com/electron/-/electron-19.1.3.tgz#90a2b6c3d738789d657477d87d1539f008be6536" integrity sha512-P2kfFc8UqVvPHE1w9qTZSPNpfOqd+CK34K3wBqJwokzYdVBLsVkbIoLxyByjJ/cU35WaeCL5bsI8kXALfPvebw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"
Change:
set up two panes open a diff editor in the left pane open the keybindings UI in the left pane open another file in the right pane click on a modified file in the SCM ui the diff editor doesn't get opened or revealed, making the click appear to be a no-op ( this doesn't repro in stable ) https://user-

Discussion:
} override matches(otherInput: EditorInput | IUntypedEditorInput): boolean { <del> return super.matches(otherInput) || otherInput instanceof KeybindingsEditorInput; </del> <ins> return otherInput instanceof KeybindingsEditorInput; </ins> } override dispose(): void {
Change:
! Here is me triggering run task, it pops up very slowly in todays insiders.
This is most likely because we have to wait for many things before we can provide tasks. Do you see in the status bar an extensions loading spinner?
No the spinner only flashes for like one millisecond. I notice it's slow only when in a repo with just NPM tasks.
which repo are you in there?
this has started happening recently for you, correct?
Yeah, within this iteration. I was on vacation so don't have a better time estimate
I am also experiencing this since updating to the latest VS code version (1.72)
can you share your file?

Discussion:
const identifier = this._getTaskIdentifier(arg); const type = arg && typeof arg !== 'string' && 'type' in arg ? arg.type : undefined; const task = arg && typeof arg !== 'string' && 'task' in arg ? arg.task : arg === 'string' ? arg : undefined; <ins> if (!identifier && !task && !type) { return this._doRunTaskCommand(); } </ins> this._getGroupedTasks().then(async (grouped) => { const tasks = grouped.all(); const resolver = this._createResolver(grouped);

} } const exactMatchTask = tasks.find(t => task && (t.getDefinition(true)?.configurationProperties?.identifier === task || t.configurationProperties?.identifier === task || t._label === task)); <del> const atLeastOneMatch = tasks.some(t => { if (task) { if (t._label.includes(task)) { if (!type || t.type === type) { return true; } } } else if (type && t.type === type) { return true; } return false; }); </del> if (exactMatchTask) { const id = exactMatchTask.configurationProperties?.identifier || exactMatchTask.getDefinition(true)?.configurationProperties?.identifier; if (id) {

} } } <del> } else if (atLeastOneMatch) { return this._doRunTaskCommand(tasks, type, task); } else { return this._doRunTaskCommand(); </del> } <ins> const atLeastOneMatch = tasks.some(t => { if (task) { if (t._label.includes(task)) { if (!type || t.type === type) { return true; } } } else if (type && t.type === type) { return true; } return false; }); return atLeastOneMatch ? this._doRunTaskCommand(tasks, type, task) : this._doRunTaskCommand(); </ins> }); }
Change:
<img width="288" alt="image" src="https://user-"The search result counts previously showed the number of nodes directly under it, but it would be nice if it actually showed the number of nested matches.

Discussion:
} private renderFolderDetails(folder: FolderMatch, templateData: IFolderMatchTemplate) { <del> const count = this.searchView.isTreeLayoutViewVisible ? folder.count() : folder.recursiveFileCount(); </del> <ins> const count = folder.recursiveMatchCount(); </ins> templateData.badge.setCount(count); templateData.badge.setTitleFormat(count > 1 ? nls.localize('searchFileMatches', "{0} files found", count) : nls.localize('searchFileMatch', "{0} file found", count));

return this.downstreamFileMatches().length; } <ins> recursiveMatchCount(): number { return this.downstreamFileMatches().reduce<number>((prev, match) => prev + match.count(), 0); } </ins> get query(): ITextQuery | null { return this._query; }
Change:
Steps to Reproduce: an extension on Marketplace. its to add and to increment so it is semantically greater than the version you published in the previous step. this version as a pre-release. VS Code, view the extension's tab. By default you see the earlier version (not the pre-release). It displays the Preview badge even though its doesn't set this. this version. The Preview badge still shows. I would only expect to see the Preview badge when viewing details of a version in which the preview property is set true. For example: ! It looks like the badge uses a boolean fetched from Marketplace (aka gallery). I guess it is taking the preview flag of the newest Marketplace version, not the version actually being displayed.
does this scenario now work as expected for you?
<!-- 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!
I don't currently have any extensions in this state, and I'd rather not pollute my Marketplace to verify it. The code change looks good though, so /verified

Discussion:
description?: string; main?: string; browser?: string; <ins> preview?: boolean; </ins> // For now this only supports pointing to l10n bundle files // but it will be used for package.l10n.json files in the future l10n?: string;

} get preview(): boolean { <del> return this.gallery ? this.gallery.preview : false; </del> <ins> return this.local?.manifest.preview ?? this.gallery?.preview ?? false; </ins> } get hasPreReleaseVersion(): boolean {
Change:
Screenshot in 1.72 release notes shows a tip containing (IMO) two unnecessary repetitions of the word "Extension". ! VS Code version: Code - Insiders 1.72.0-insider (, 2022-10-04T05:43:53.890Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes

Discussion:
if (newBadgeNumber > 0) { let msg = ''; if (outdated) { <del> msg += outdated === 1 ? localize('extensionToUpdate', '{0} Extension requires update', outdated) : localize('extensionsToUpdate', '{0} Extensions require update', outdated); </del> <ins> msg += outdated === 1 ? localize('extensionToUpdate', '{0} requires update', outdated) : localize('extensionsToUpdate', '{0} require update', outdated); </ins> } if (outdated > 0 && extensionsReloadRequired.length > 0) { msg += ', '; } if (extensionsReloadRequired.length) { <del> msg += extensionsReloadRequired.length === 1 ? localize('extensionToReload', '{0} Extension requires reload', extensionsReloadRequired.length) : localize('extensionsToReload', '{0} Extensions require reload', extensionsReloadRequired.length); </del> <ins> msg += extensionsReloadRequired.length === 1 ? localize('extensionToReload', '{0} requires reload', extensionsReloadRequired.length) : localize('extensionsToReload', '{0} require reload', extensionsReloadRequired.length); </ins> } const badge = new NumberBadge(newBadgeNumber, () => msg); this.badgeHandle.value = this.activityService.showViewContainerActivity(VIEWLET_ID, { badge, clazz: 'extensions-badge count-badge' });
Change:
Notice how in the step was stuck in the following line for at around 2 hours: This could either be from or from . Maybe we should put a log between those. In any case, my bets go against the former... which can be resolved with the  option. WDYT? cc
You're a PowerShell pro now!

Discussion:
if($set.Add($artifactName)) { Write-Host "Processing artifact: '$artifactName. Downloading from: $($_.resource.downloadUrl)" <ins> $extractPath = "$env:AGENT_TEMPDIRECTORY/$artifactName.zip" </ins> try { <del> Invoke-RestMethod $_.resource.downloadUrl -OutFile "$env:AGENT_TEMPDIRECTORY/$artifactName.zip" -Headers @{ </del> <ins> Invoke-RestMethod $_.resource.downloadUrl -OutFile $extractPath -Headers @{ </ins> Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" <del> } -MaximumRetryCount 5 -RetryIntervalSec 1  | Out-Null </del> <ins> } -MaximumRetryCount 5 -RetryIntervalSec 1 -TimeoutSec 300 | Out-Null </ins> <del> Expand-Archive -Path "$env:AGENT_TEMPDIRECTORY/$artifactName.zip" -DestinationPath $env:AGENT_TEMPDIRECTORY | Out-Null </del> <ins> Write-Host "Extracting artifact: '$extractPath'" Expand-Archive -Path $extractPath -DestinationPath $env:AGENT_TEMPDIRECTORY | Out-Null </ins> } catch { Write-Warning $_ $set.Remove($artifactName) | Out-Null
Change:
Do we do this for other widgets? It seemed off to me at first sight. <img width="405" alt="CleanShot 2022-10-04 at 09 58 26 src="https://user-"

Discussion:
this._allMenuItems = items; this._list.splice(0, this._list.length, this._allMenuItems); <del> this.focusNext(); </del> <ins> if (this._list.length) { this.focusNext(); } </ins> } private focusCondition(element: IListMenuItem<IActionItem>): boolean {

border-width: 0 !important; } <ins> .action-widget .monaco-list:focus:before { outline: 0 !important; } </ins> .action-widget .monaco-list .monaco-scrollable-element .monaco-list-rows { height: 100% !important; }
Change:
Debug some js code Set a breakpoint Click the toggle button to deactivate all breakpoints The unbound breakpoint warning indicator shows up
<img width="639" alt="image" src="https://user-"

Discussion:
return langId && dbg.interestedInLanguage(langId); }); <del> if (message && debuggerHasUnverifiedBps?.length) { </del> <ins> if (message && debuggerHasUnverifiedBps?.length && this.debugService.getModel().areBreakpointsActivated()) { </ins> if (delayed) { const mdown = new MarkdownString(undefined, { isTrusted: true }).appendMarkdown(message); this.hintContainer.setLabel('$(warning)', undefined, { title: { markdown: mdown, markdownNotSupportedFallback: message } });
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.71.2 (user setup) Commit: Date: 2022-09-14T21:03:37.738Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No OS Version: Windows 10 Steps to Reproduce: Use a snippet that has repeat placeholder variables, e.g. command palette, select "Insert snippet" the list of available snippets, select using the mouse to left click on it typing to fill in the highlighted/selected placeholder variable text editor does not have focus. (If you manually select the text editor for focus, it is very easy to lose the multiple cursor focus which is essential for efficiently 'filling in' the snippet) This is an accessibility issue, which arose while using eye control for coding, but the issue persists when just using conventional mouse control. This video shows the correct behaviour, with focus immediately moved to the text file with correct cursor selection when keyboard control is used to select a snippet. Note that NumPad2 is being used as a shortcut for 'tabbing' to the next placeholder, to avoid other conflicts: This video shows the bug, with focus lost when mouse control is used to select a snippet.
I will push a change to explicitly set focus back to the editor after having interacted with quick pick. However, this looks like an issue with quick pick itself, that fact that clicking vs key-down is different seems y and other might be affected by this as well
Thanks for the quick investigation. We are getting on really well with eye control otherwise, and getting snippets working flawlessly is going to be a big win!
since you are out, I'll move this to next iteration.
fixed the actual bug... and the focus stuff is covered by
Cough, cough. IMO is the actual bug and affected folks are implementing workarounds
Agreed

Discussion:
if (snippet.needsClipboard) { clipboardText = await clipboardService.readText(); } <ins> editor.focus(); </ins> SnippetController2.get(editor)?.insert(snippet.codeSnippet, { clipboardText }); snippetService.updateUsageTimestamp(snippet); }

clipboardText = await clipboardService.readText(); } <ins> editor.focus(); </ins> SnippetController2.get(editor)?.insert(snippet.codeSnippet, { clipboardText }); snippetsService.updateUsageTimestamp(snippet); }
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. --In Visual Studio, the symbol is considered a trigger character inside JSDocs, and so the appropriate completions are displayed without having to use ctrl + Space. ! It would be great if this was also offered by VS Code :)
Are trigger characters supposed to override the setting? We disable quick suggestions in comments by default
It seems like VS Code already has some smarts to know that things are a little different within a JSDoc tag's . How does that work?
We treat the parts inside of as being code again. This is done using some textmate grammar tricks (there's a special scope that tells VS Code to treat this part of the comment as code) This doesn't apply when you type though as it still looks like we're in a normal comment at that point
Yes, trigger characters are "stronger" than quick suggest and work independent of the setting. However, a trigger character that's also a word character is considered a quick suggest case (hand the setting will apply).
Quick update: If I set , then I get completions after typing inside JSDocs. This isn't great though because then I also get snippet completions (e.g. after typing a ). It would be great if JSDocs could be treated as special comments where just a subset of completions is valid (not sure if this involves changes from VS Code or TypeScript).
This is the current experience in Visual Studio BTW.
This works if I revert . Since this seems more important, I'll do that and reopen
<!-- 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

Discussion:
} }, "wordPattern": { <del> "pattern": "(-?d*.dw*)|([^`~!%^&*()-=+[{]}|;:'",.<>/?s]+)", </del> <ins> "pattern": "(-?d*.dw*)|([^`~@!%^&*()-=+[{]}|;:'",.<>/?s]+)", </ins> }, "indentationRules": { "decreaseIndentPattern": {

} }, "wordPattern": { <del> "pattern": "(-?d*.dw*)|([^`~!%^&*()-=+[{]}|;:'",.<>/?s]+)", </del> <ins> "pattern": "(-?d*.dw*)|([^`@~!%^&*()-=+[{]}|;:'",.<>/?s]+)", </ins> }, "indentationRules": { "decreaseIndentPattern": {
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: Python extension we use in our walkthrough to open a Python file while user is working with the walkthrough: . occupies more than half of the space and requires adjusting the column again: ! this to bicep extension where it opens up nicely: ! They used their own command: which we cannot use in the Python extension. We have to rely on VSCode command itself: , so a python file can be opened without waiting for extension to activate. More context: cc/
I am not sure who owns this today, I think Logan?
I can verify this occupies half space now, although I think it should be opened to the right side like bicep as the main context is still getting started.
Verified. I agree it should be opened to the right side,
Could you please open another issue for that? Thanks.

Discussion:
if (this.groupsService.count === 1) { this.groupsService.addGroup(this.groupsService.groups[0], GroupDirection.LEFT, { activate: true }); <del> let gettingStartedSize: number; if (fullSize.width > 1600) { gettingStartedSize = 800; } else if (fullSize.width > 800) { gettingStartedSize = 400; } else { gettingStartedSize = 350; } </del> <ins> const gettingStartedSize = Math.floor(fullSize.width / 2); </ins> const gettingStartedGroup = this.groupsService.getGroups(GroupsOrder.MOST_RECENTLY_ACTIVE).find(group => (group.activeEditor instanceof GettingStartedInput)); this.groupsService.setSize(assertIsDefined(gettingStartedGroup), { width: gettingStartedSize, height: fullSize.height });
Change:
<img width="626" alt="CleanShot 2022-10-07 at 10 18 27 src="https://user-"

Discussion:
.monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlide .getting-started-category .featured .featured-icon { top: -30px; left: 4px; <del> font-size: 12pt; </del> <ins> font-size: 14px; </ins> } .monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlide .getting-started-category .codicon.hide-category-button {
Change:
Type: <bBug</bWhen rebasing a big change on the TypeScript codebase today, I ended up with a diff that didn't make sense; I traced it down to having committed the wrong newlines. I am in WSL2, so the line ending VS Code uses is LF. However, the TS repo's files are CRLF, and are checked out as CRLF even on Linux. (Normally, VS Code saves LF, then I convert it to CRLF after a lint rule complains; in the future I'll probably just use the line ending setting and hope it works.) When I was rebasing, I hit a merge conflict; I opened the conflicted file in the source control view, and did my merge. But, when I committed the file, it appears as though the file was saved as LF and I committed it like that. I ended up having to rebase my whole stack again and run unix2dos on each until I restored the line endings. I recall something in the update blog post mentioning that the merge editor was implemented by reconstructing a new document from the two input files; perhaps this isn't taking into account the line endings of the original files? I don't recall this happening in previous versions. VS Code version: Code 1.72.0 (, 2022-10-04T23:20:39.912Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.15.57.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ remote-wsl0.72.0 atom-keybindings3.0.9 material-theme3.15.5 gitlens12.2.2 todo-tree0.0.215 vscode-duplicate1.2.1 js-debug-nightly2022.10.617 vscode-typescript-next4.9. </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I cannot reproduce (on windows, with CRLF as VS Code default and LF files). Can you reproduce? (ideally with steps on a fresh repository) It should use the line-endings style from the result file.
This just occurred to me again just the following day; I can reproduce this with a cherry pick, so that is probably going to be easier for me to make an examples with. I'll try and make one.
Also, you are using the new 3 way merge editor, right (explicitly clicking the blue button in the bottom "Open/Resolve in Merge Editor")?
Yes, that's correct, not the inline one where it's just sugar on top of a file with the lines.
I've made an example repo here: It reproduces reliably for me. Here's a screencast. !
Thank you, I can reproduce it now! Unfortunately it always resets the EOL to LF (in my test, I checked if LF files stay LF files after merging, as CRLF is the default on my system). I (implicitly) assumed would normalize the EOL style the same way does, which is apparently not the case.
Many thanks!
Verification steps: Have a conflict in a repo where all files are CLRF Solve the conflicts in the new merge editor and complete the merge Ensure the staged file also has CRLF line endings Do the same with LF files.

Discussion:
appendLinesToResult(baseLines, LineRange.fromLineNumbers(baseStartLineNumber, baseLines.length + 1)); <del> return resultLines.join('n'); </del> <ins> return resultLines.join(this.resultTextModel.getEOL()); </ins> } public hasBaseRange(baseRange: ModifiedBaseRange): boolean {