jiebi/CodeConvo huggingface dataset:
Code change:
resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0.tgz#41c0d96acc1e3bb6c6596eee64e163b6bca74be7" integrity sha512-Jm4/g4QiTxiKiTbYICQgC791ubhIZyoIwxAIgOW8z8HWFNY+lwk+dwaKEaEeGBfM48Vk8fklsUW9u/PlenYEBg== <del> xterm-addon-webgl@0.15.0-beta.8: version "0.15.0-beta.8" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.8.tgz#2005198582f6f1f4a9b2612b9354c0bcc9f148d8" integrity sha512-HjTr9bi3FvdOIPaaIpih6qdHX2z+H7sQPluLj5KzwCqRiEVUVRi19dl8SdHjf6dCmN3GahMhjV7D+zxHi2pLTw== </del> <ins> xterm-addon-webgl@0.15.0-beta.10: version "0.15.0-beta.10" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.10.tgz#39ebbfb1b89c6773a2d8cb8e1d2f3ef1f08b28f9" integrity sha512-JVv4t5q6QGWyLiEAcAk9H2B83hFlIalzEwWu1VVYso0MJyZAlZ0NP5Za03iSKxYi7RQIA5bOe8r7W24esQDjLg== </ins> <del> xterm-headless@5.2.0-beta.35: version "5.2.0-beta.35" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.35.tgz#8c3d4d06747e27a5bc4f0bf914479820a5b8f529" integrity sha512-tq/zKnXEsVXGlhXHGNqPO47x9Fvew2avZ0wfMI1G80AEYrjxGY/3Quxwe9/C5ngIuPwk2CMbgDZwHhSFvyOrMA== </del> <ins> xterm-headless@5.2.0-beta.40: version "5.2.0-beta.40" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.40.tgz#6edba318d23ed350c8ec6279e6f61f40bde9b163" integrity sha512-6CHgR64POfa24CTILcq/HHg1im1u1HjJZSHWjlopP18KiS8Rq8dzCurZDsu38atxDK9dyjV8SRw2AB4ijcxZsQ== </ins> <del> xterm@5.2.0-beta.35: version "5.2.0-beta.35" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.35.tgz#4a0c0aa81c89c42167c22d023648cced44fa3c25" integrity sha512-6x6i61lucRrLWRKFeMO/ZOx5anvYR6FHpReLO2g0y1bp5zYWyZFzM6DepMV50729gubzxSLB8mvbmb9EpeIugQ== </del> <ins> xterm@5.2.0-beta.40: version "5.2.0-beta.40" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.40.tgz#c73d5576425dcd4fa6b48ce58b4224a7b5b9dbdf" integrity sha512-7/Db3KPceM0VX4/YAKL+/ArvEHlGBwE3kt1oN9QP5TLaJ6r2ThMS7z7QwG8g2gy60GFnvjfvpcTv6Ewyste4zg== </ins> y18n@^3.2.1: version "3.2.2"

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: OS Version: Steps to Reproduce: a terminal window within vscode and run this command: vscode hangs indefinitely, using 100% CPU on one core. It would be nice if that didn't happen.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I'm using web version (Vscode Server) and this code snippet cause the entirely browser tab to crash: ! Wanted to provide profiling info but profiler hanged too
I can reproduce
Nice find
Upstream:
Code change:
import { FontMeasurements } from 'vs/editor/browser/config/fontMeasurements'; import { IEditorOptions } from 'vs/editor/common/config/editorOptions'; import { BareFontInfo } from 'vs/editor/common/config/fontInfo'; <del> import { IConfigurationChangeEvent, IConfigurationService } from 'vs/platform/configuration/common/configuration'; </del> <ins> import { ConfigurationTarget, IConfigurationChangeEvent, IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> import { InteractiveWindowCollapseCodeCells, NotebookCellDefaultCollapseConfig, NotebookCellInternalMetadata, NotebookSetting, ShowCellStatusBarType } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookExecutionStateService } from 'vs/workbench/contrib/notebook/common/notebookExecutionStateService';

Related discussion:
text: Testing There are "" "notebook.outputLineHeight" "" "notebook.outputFontFamily" "notebook.outputFontSize" Ideally these would be all namespaced or prefixed .
This affects how they show up in the settings editor UI, btw: <img width="919" alt="image" src="https://user-"
Code change:
{ actionViewItemProvider: action => this.actionViewItemProvider(action as Action), actionRunner: this.actionRunner, <del> classNames: 'toolbar-toggle-pickReactions', </del> <ins> classNames: ['toolbar-toggle-pickReactions', ...Codicon.reactions.classNamesArray], </ins> anchorAlignmentProvider: () => AnchorAlignment.RIGHT } );

Related discussion:
text: Microsoft/vscode Tested using VoiceOver on MacOS Issues The add reaction button on the right side is currently read out atWhen focusing on a reaction in the context menu, it is read as just the emoji name. Github instead reads each option asThe existing reactions do not have helpful voice text. They should be read as the reaction name and number of reactionsThe add reaction button the right of existing reactions also does not have helpful voice over labels
This is now read as "Toggle Reaction" Since this uses a context menu, this is intentional. Menus don't have special aria labels. This now reads a more useful "Toggle reaction, x reactions with y" message. Same as above since this is a menu.
This seems improved but I can't get it to read the menu when I tab from the comment to the react menu button. It doesn't read anything when I use the arrow keys to move focus between menu buttons. If I expand the menu with space, then it reads the menu name. It looks like this, so I guess voiceover is stuck on the full comment context even though focus has moved. Not a voiceover expert though, is that an issue or should I be using other nav keys anyway? <img width="610" alt="image" src="https://user-"
Code change:
description: localize('chatSampleRequest', "When the user clicks this participant in `/help`, this text will be submitted to the participant."), type: 'string' }, <ins> when: { description: localize('chatParticipantWhen', "A condition which must be true to enable this participant."), type: 'string' }, </ins> commands: { markdownDescription: localize('chatCommandsDescription', "Commands available for this chat participant, which the user can invoke with a `/`."), type: 'array',

Related discussion:
text: The static "when" clause on chat participants should be moved to the set of things that are finalized.
what would happen when a participant becomes "disabled" after having been interacted with? Evaluating going from to and to again
It would just stop showing up in the suggest widget and you wouldn't be able to invoke it. But it can still show up in your conversation thread. Same as if you uninstall a chat extension.
Verify that can be set and used on the chat participant contribution in without api proposal needed. Easiest to use the .
Code change:
value: this.state.text.value, placeholderText: localize('testExplorerFilter', "Filter (e.g. text, !exclude, @tag)"), }, <del> history: this.history.get([]) </del> <ins> history </ins> })); this._register(attachSuggestEnabledInputBoxStyler(input, this.themeService));

Related discussion:
text: Issue Type: <bFeature Request</b The Test Explorer filter should be preserved if a window reload occurs, rather than resetting to default. This behavior could be gated by a setting. ! VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-16T05:16:18.653Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (32)</summaryExtensionVersion ------ vscode-color0.4.5 vscode-opennewinstance0.0.12 gitlens11.7.0 filter-lines1.0.0 EditorConfig0.16.4 prettier-vscode9.2.0 copilot-nightly1.7.5030 remotehub0.24.0 gc-excelviewer4.0.50 todo-tree0.0.215 vscode-drawio1.6.4 change-case1.0.2 vscode-peacock4.0.0 git-graph1.30.0 vscode-azurefunctions1.6.0 vscode-azureresourcegroups0.4.0 vscode-docker1.19.0 remote-containers0.222.0 azure-account0.10.0 powershell-preview2022.2.1 indent-rainbow8.2.2 docthis0.8.2 pester-test2021.10.2 vscode-commons0.0.6 vscode-yaml1.4.0 vscode-inline-values-powershell0.0.5 errorlens3.4.1 vscode-icons11.10.0 codetour0.0.58 gistfs0.3.0 gitmoji-vscode1.0.9 better-align1.1.6 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
That makes sense.
I'm still able to reproduce this with the latest mainline build. May I pick this up since it's still open?
Sure!
Code change:
} } <del> // Clear attrs, reset cursor position, clear right </del> <ins> // Get the line content of the command from the terminal </ins> const content = this._serializeAddon.serialize({ range: { start: stickyScrollLineStart + rowOffset,

Related discussion:
text: Testing So I was testing the terminal sticky scroll and I noticed that the sticky code block disappears in an abrupt manner when the beginning (not the end) of the multiline terminal command, reaches the end of the scope. To give more context about what I mean, I the GIF below. I was sort of expecting the code block to start disappearing when the line reached the end of the output for that command. I noticed that the code block disappeared however when the line reached the end of the output for that run. I don't think this is a problem per say, it's a different manner of animating sticky scroll. I was just wondering if this is intended? I think the potential issue with this approach is that the sticky scroll block is hiding the next terminal command and its output while you are scrolling until it disappears. In the editor, sticky scroll starts disappearing progressively when the bottom of the last block/line touches the end of the scope. Perhaps we could explore something similar?
This is actually a bug, it's meant to scroll up as in the editor and was doing that at some point. Note that it's not as smooth as the editor since there's no "partial line scrolling" in the terminal
Repro that demonstrates more clearly what's happening: Run: Run: Run: when scrolling, sticky scroll from a command should never obscure the command below it like this: !
I see the prompt line sort of being obscured here
Code change:
* interval. */ KillSpawnSpacingDuration = 50, <del> /** * Writing large amounts of data can be corrupted for some reason, after looking into this is * appears to be a race condition around writing to the FD which may be based on how powerful * the hardware is. The workaround for this is to space out when large amounts of data is being * written to the terminal. See https://github.com/microsoft/vscode/issues/38137 */ WriteMaxChunkSize = 50, </del> /** * How long to wait between chunk writes. */

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?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.77.3 OS Version: Ubuntu 20.04.6 Steps to Reproduce: VSCode on an Ubuntu computer (or on Windows using WSL) the built-in terminal the command and paste the following 39-character string into nano: : nano shows the error message "Unknown Sequence". Can no longer interact with the terminal, need to kill it and open a new one More details: nano version 4.8 This does not happen in nano using an external terminal. Only in VSCode's built-in terminal This does not happen for any other length of string, even other multiples of 39 This does not happen in other CLI text editors, such as vim
I can confirm this issue on Windows using WSL.
It happens with other 39 long strings as well. It also happens when not using WSL. Copying more characters solves the problem. For us it also happens with multiples of 39 (e.g. 156 characters, line breaks included)
When trace logs are enabled this is the exact sequence we send: Compared to 1 less : Note that the 200/201 wrapped around it is bracketed paste mode (which I just a way to disable so that may help ). So this seems to be either a problem with one of nano, conpty or node-pty.
I also just ran into this. I'm on Windows 10, using Remote - SSH plugin to connect to an Ubuntu 22.04 server. Right-click to paste in Nano, terminal locks up, have to Kill it.
Code change:
* interval. */ KillSpawnSpacingDuration = 50, <del> /** * Writing large amounts of data can be corrupted for some reason, after looking into this is * appears to be a race condition around writing to the FD which may be based on how powerful * the hardware is. The workaround for this is to space out when large amounts of data is being * written to the terminal. See https://github.com/microsoft/vscode/issues/38137 */ WriteMaxChunkSize = 50, </del> /** * How long to wait between chunk writes. */

Related discussion:
text: Add/remove one character from the string and try again, works.
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!
i opened a bug on gnu nano's bugtracker:
I think I found a workaround, but haven't tested it: vscode , nano doesn't deal well with across writes and it is apparently difficult to fix in nano. vscode could split writes differently, using this algorithm that keeps escape sequences at the beginning and end unsplit (like bracketed pastes):
great info, we should definitely do this . I'll probably tweak your proposal a little to try catch escape sequences in the middle too.
I don't expect input sizes to be 50 bytes except when pasting, when pasting there should only ever be an escape sequence at the beginning and end, never in the middle (terminal apps are unlikely to deal well with pasting a string containing escape sequences anyway).
unless I missed something in the issue you linked, it's not that they need to be on the boundaries of the text but need to be included entirely in that string and not clipped?
yes, escape sequences need to be contained entirely in one write syscall. basically I am saying you shouldn't have escape sequences in the middle of a long input, so you don't need to look for them to avoid splitting them, they should only occur towards the ends of a long input or in a shorter input.
Nano's workaround was released in Nano 8.0:
Code change:
storageId: 'workbench.explorer.views.state', icon: explorerViewIcon, alwaysUseContainerInfo: true, <ins> hideIfEmpty: true, </ins> order: 0, openCommandActionDescriptor: { id: VIEWLET_ID,

Related discussion:
text: Testing open search viewlet drag explorer (activity icon) into search pane all explorer views are now in the search pane it is not possible to drag the file/folder view back into the explorer https://user-
verified since the empty explorer is gone
Code change:
storageId: 'workbench.explorer.views.state', icon: explorerViewIcon, alwaysUseContainerInfo: true, <ins> hideIfEmpty: true, </ins> order: 0, openCommandActionDescriptor: { id: VIEWLET_ID,

Related discussion:
text: Testing have search view open drag the explorer icon onto it the explorer (and npm script) views show the explorer icon stays in the activity bar, the view is empty https://user-
Code change:
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

Related discussion:
text: 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!
Code change:
item: { command: { id: TerminalCommandId.SelectDefaultProfile, <del> title: { value: localize('workbench.action.terminal.selectDefaultProfile', "Select Default Profile"), original: 'Select Default Profile' } </del> <ins> title: { value: localize('workbench.action.terminal.selectDefaultProfile', "Select Default Profile"), original: 'Select Default Profile' }, </ins> }, <del> group: TerminalTabContextMenuGroup.Configure </del> <ins> group: '3_configure' </ins> } }, {

Related discussion:
text: Could look like this, but have and/or tasks entries as well as a one. Hiding it by default is a good way to avoid cluttering the action bar - so people only see it if they want to <img width="285" alt="Screen Shot 2022-09-30 at 12 56 57 PM" src="https://user-"
cc
Talked w Kai and we're thinking to instead add a action to the terminal dropdown which aligns with the menu and will aid in discoverability !
Code change:
const content = []; content.push(this._descriptionForCommand(TerminalCommandId.FocusAccessibleBuffer, localize('focusAccessibleTerminalView', 'The Focus Accessible Terminal View ({0}) command enables screen readers to read terminal contents.'), localize('focusAccessibleTerminalViewNoKb', 'The Focus Terminal Accessible View command enables screen readers to read terminal contents and is currently not triggerable by a keybinding.'))); content.push(localize('preserveCursor', 'Customize the behavior of the cursor when toggling between the terminal and accessible view with `terminal.integrated.accessibleViewPreserveCursorPosition.`')); <ins> if (!this._configurationService.getValue(TerminalSettingId.AccessibleViewFocusOnCommandExecution)) { content.push(localize('focusViewOnExecution', 'Enable `terminal.integrated.accessibleViewFocusOnCommandExecution` to automatically focus the terminal accessible view when a command is executed in the terminal.')); } </ins> if (this._instance.shellType === WindowsShellType.CommandPrompt) { content.push(localize('commandPromptMigration', "Consider using powershell instead of command prompt for an improved experience")); }

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?
Code change:
constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }

Related discussion:
text: Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?