jiebi/CodeConvo huggingface dataset:
Change:
registerSimpleEditorSettingMigration('autoIndent', [[false, 'advanced'], [true, 'full']]); registerSimpleEditorSettingMigration('matchBrackets', [[true, 'always'], [false, 'never']]); registerSimpleEditorSettingMigration('renderFinalNewline', [[true, 'on'], [false, 'off']]); <ins> registerSimpleEditorSettingMigration('cursorSmoothCaretAnimation', [[true, 'on'], [false, 'off']]); </ins> registerEditorSettingMigration('autoClosingBrackets', (value, read, write) => { if (value === false) {

Discussion:
Type: <bBug</bthe set to the cursor around with arrows. Animation is there. something. Animation is not there. VS Code version: Code - Insiders 1.75.0-insider (, 2022-12-12T05:36:38.306Z) OS version: Darwin arm64 22.1.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ better-comments3.0.2 vscode-nginx-conf0.1.3 ng-template15.0.2 vscode-tailwindcss0.9.1 better-toml0.3.2 npm-intellisense1.4.3 vscode-eslint2.3.0 vscode-quick-select0.2.9 xml2.5.1 gitlens13.1.1 scroll-faster0.2.2 prettier-vscode9.10.3 vscode-jest-runner0.4.59 auto-rename-tag0.1.10 shell-format7.2.2 macros1.2.1 vscode-pull-request-github0.57. vscode-postfix-ts1.11.3 Angular213.0.0 center-editor-window2.3.0 graphql-for-vscode1.15.3 vscode-clangd0.1.23 ts-error-translator0.5.1 dotenv1.0.1 vscode-docker1.23.1 black-formatter2022.7. isort2022.9. python2022.21. vscode-pylance2022.12.21 vscode-typescript-next5.0. vsliveshare1.0.5788 prisma4.7.1 vscode-yaml1.10.1 better-pageup-pagedown0.0.1 rust-analyzer0.4.1316 vs-code-prettier-eslint5.0.4 justfile2.1.0 vscode-scss-formatter2.4.4 shellcheck0.29.1 vscode-input-sequence0.2.0 errorlens3.6.0 vscode-lldb1.8.1 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Maybe related to /assign
This was an intentional change to disable the animation when typing/deleting.

See
okay, that makes perfect sense. closing.
Also having the same issue. Has there been a fix?
We have intentionally removed animating the cursor when typing for which explicitly asks us to do that. But I think some folks actually prefered the old behavior of animating also when typing?
Yes, I love the animating when typing.
A good common ground could be that it becomes a setting to also have the caret animated while typing
I've pushed a change where there will be 3 possible values for : off: Smooth caret animation is disabled explicit: Smooth caret animation is enabled only when the user moves the cursor with an explicit gesture. This should cover users who don't want it like in issue on: Smooth caret animation is always enabled
thank you for the changes. I noticed now cursorSmoothCaretAnimation is turned on by default and can't be turned off at all. Looks like a bug.
see which is already fixed.
Change:
import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; import { IOpenerService } from 'vs/platform/opener/common/opener'; import { URI } from 'vs/base/common/uri'; <ins> import { IRemoteExplorerService } from 'vs/workbench/services/remote/common/remoteExplorerService'; </ins> export class TunnelFactoryContribution extends Disposable implements IWorkbenchContribution { constructor( @ITunnelService tunnelService: ITunnelService, @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService, <del> @IOpenerService openerService: IOpenerService </del> <ins> @IOpenerService openerService: IOpenerService, @IRemoteExplorerService remoteExplorerService: IRemoteExplorerService </ins> ) { super(); const tunnelFactory = environmentService.options?.tunnelProvider?.tunnelFactory;

Discussion:
Automatic port forwarding waits for environment tunnels to be set before starting. However, environment tunnels are not set with embedders.
Change:
} public disable(): void { <ins> this.blur(); </ins> this.input.disabled = true; this._hideMessage(); }

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: code-server2.1692-vsc1.39.2-linux-x86_64 and a few previous OS Version: Fedora 31 Firefox 70 @ Windows 10 1909 I am running VS Code remotely via code-server. When I use Find function to search something, then press Esc to exit search field and try to insert a new line by Enter, the search field is opened instead of inserting a new line. It works fine in Chrome though. +F, type a text, press Enter Esc to exit search field, eventually press End to deselect found text Enter field is opened again instead of inserting a new line <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.482 --<!-- potentialduplicatescomment --
A similar issue was reported for the monaco-editor. The cause and fix should be the same, so I'm linking it here:
Yes, monaco playground behaves the same on my side.
I wonder if this issue is reproducible when running VSCode in a browser. We allow to run VSCode in a very simplified form in a browser following these steps: setup to be able to run VSCode out of sources: run from a command line it should open a browser with VSCode running If you are not able to set this up, we also provide a hosted version of VSCode for Web at: https://vscode-web-test- Does the issue reproduce in that setup in the browser?
I just tried the web version and it reproduces there, too.
I have tested the playground on azurewebsites and the issue is reproducible. !
Thanks for testing
This problem happens to me too, when using codercom/code-server:2.1688-vsc1.39.2 in Firefox Linux. Enter starts working again when you close the Find box enough times by clicking it instead of pressing Escape.
Change:
import { widgetClose } from 'vs/platform/theme/common/iconRegistry'; import { attachProgressBarStyler } from 'vs/platform/theme/common/styler'; import { IColorTheme, IThemeService, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; <ins> import { parseReplaceString, ReplacePattern } from 'vs/editor/contrib/find/replacePattern'; </ins> const NLS_FIND_INPUT_LABEL = nls.localize('label.find', "Find"); const NLS_FIND_INPUT_" = nls.localize('placeholder.find', "Find");

Discussion:
<!-- 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 Jupyter Notebooks, finding witrh regex works but replacing with capturing groups doesn't. I'd like if it does. I tried as in the usual editor, but the replacement treats as literal. I had to work around by copying the code section to the usual editor, and then find and replace. This seems like an inconsistent UX, and personally quite inconvinient.
Should I have opened this at ? If so, please close this so I can move on.
Thanks again for the help, it makes the find experience in notebook closer to the normal text editor one.
did you create a test plan item for this? I just the verification needed to it.
Change:
import { Registry } from 'vs/platform/registry/common/platform'; export interface IGutterActionsGenerator { <del> (context: { lineNumber: number; editor: ICodeEditor; accessor: ServicesAccessor }, result: { push(action: IAction): void }): void; </del> <ins> (context: { lineNumber: number; editor: ICodeEditor; accessor: ServicesAccessor }, result: { push(action: IAction, group?: string): void }): void; </ins> } export class GutterActionsRegistryImpl {

Discussion:
configure "testing.defaultGutterClickAction": "contextMenu", open a test file and click on a test icon a context menu opens but the test commands aren't atop <img width="356" alt="Screenshot 2023-03-31 at 15 41 37" src="https://user-"
Change:
dependencies: object-keys "~0.4.0" <del> xterm-addon-canvas@0.3.0-beta.23: version "0.3.0-beta.23" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.3.0-beta.23.tgz#aa67f43114e0bd052311f3f88f842e85006e697f" integrity sha512-xFeuwK1ZuIl+5Go4ZesAWe+pToqjF0LSQfECia3tTZ0emkpzR3c+wU3vWoKPj71A7ZkgCVDmCGyLAWDpTSLgEQ== </del> <ins> xterm-addon-canvas@0.3.0-beta.26: version "0.3.0-beta.26" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.3.0-beta.26.tgz#8c5665477d168f0c075960d9d86ae21afb3000c4" integrity sha512-33Btfufs6u8YsU8jmLlQfmmqavKGvP5s4Clxwq+KTT5DIlYDmt0r8GKdBHrB0AwNZiFRXsbPQoLF2XkHnkpTEw== </ins> xterm-addon-search@0.11.0-beta.7: version "0.11.0-beta.7"

Discussion:
Issue Type: <bPerformance Issue</bEver since I got this M1 mac with apple silicon, any scrolling I do in VSCode is super choppy and laggy. To reproduce it on my machine I just need to open an editor with a scrollbar or a terminal with some history and scroll quickly up and down. VS Code version: Code 1.69.2 (, 2022-07-18T16:32:39.000Z) OS version: Darwin arm64 21.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryProcess Info</summary</details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (11)</summaryExtensionVersion ------ prettier-vscode9.5.0 go0.35.1 githd2.3.3 vscode-docker1.22.1 python2022.10.1 vscode-pylance2022.8.10 jupyter2022.6. jupyter-keymap1.0.0 jupyter-renderers1.0.9 vsliveshare1.0.5669 vscode-yaml1.9.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Can you do a performance profile in devtools (Help Toggle Developer Tools) and upload it here? !
Sure, attached.
Hey this issue might need further attention. you can help us out by closing this issue if the problem no longer exists, or adding more information.
There's an abnormal about of garbage collection in that profile which I've never seen before: !
what sort of monitor are you connected to? Could you also open devtools via the Help menu and run in the console? My guess is your font size is so large that the terminal's texture atlas is thrashing and redrawing all glyphs almost every frame.
Upstream issue tracking the texture cap problem:
This one can only be verified by the
<!-- 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'll mark this issue as verified as part of . Please file a new issue if the bug continues to occur on the latest Stable and/or Insiders versions of VS Code.
Change:
// When saving, try to just download the contents // of the active text editor if any as a workaround if (context === 'save') { <del> const activeTextModel = this.codeEditorService.getActiveCodeEditor()?.getModel(); if (activeTextModel) { triggerDownload(VSBuffer.fromString(activeTextModel.getValue()).buffer, basename(activeTextModel.uri)); return; </del> <ins> const activeCodeEditor = this.codeEditorService.getActiveCodeEditor(); if (!(activeCodeEditor instanceof EmbeddedCodeEditorWidget)) { const activeTextModel = activeCodeEditor?.getModel(); if (activeTextModel) { triggerDownload(VSBuffer.fromString(activeTextModel.getValue()).buffer, basename(activeTextModel.uri)); return; } </ins> } }

Discussion:
We use in some places to get at the currently focused code editor. To my surprise, this method seems to be returning that are used for example as Copilot chat input. I would argue that in most if not all our usages, we only care about text editors that contain contents of a document, but not input fields like that. Can we add some kind of filter logic or a way for the caller to know if the returned editor is used as input field?
I don't know exactly what uses, but can be used to find out if this editor instance is an "input field".
Got it, I am not sure how big of an issue this is today for everyone using the API, but I will check for my usages.
Yeah, that's what I use too
Change:
* Builds the model from scratch based on the current state of the editor service. */ private _createTabsModel(): void { <ins> if (this._editorGroupsService.groups.length === 0) { return; // skip this invalid state, it may happen when the entire editor area is transitioning to other state ("editor working sets") } </ins> this._tabGroupModel = []; this._groupLookup.clear(); this._tabInfoLookup.clear();

Discussion:
Branch - ben/editor-working-sets-api-command
here are steps: enable the new setting to open a folder that has a git repo and checkout to a branch open some editors checkout back to the main branch (editor layout should change) =this stack trace appears Since we are planning to build this feature for April, I would appreciate a quick look from you.
I am pushing a fix, during the working set transition there is a brief moment when there are no editor groups...
<!-- 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!
Change:
assert.ok(inserted.innerHTML.indexOf('>second stream content</') === -1, `Content was not cleared: ${outputElement.innerHTML}`); assert.ok(inserted.innerHTML.indexOf('>third stream content</') === -1, `Content was not cleared: ${outputElement.innerHTML}`); }); <ins> test(`Rendered output will wrap on settings change event`, async () => { const context = createContext({ outputWordWrap: false, outputScrolling: true }); const renderer = await activate(context); assert.ok(renderer, 'Renderer not created'); const outputElement = new OutputHtml().getFirstOuputElement(); const outputItem = createOutputItem('content', stdoutMimeType); await renderer!.renderOutputItem(outputItem, outputElement); fireSettingsChange({ outputWordWrap: true, outputScrolling: true }); const inserted = outputElement.firstChild as HTMLElement; assert.ok(inserted.classList.contains('word-wrap') && inserted.classList.contains('scrollable'), `output content classList should contain word-wrap and scrollable ${inserted.classList}`); }); test(`Settings event change listeners should not grow if output is re-rendered`, async () => { const context = createContext({ outputWordWrap: false }); const renderer = await activate(context); assert.ok(renderer, 'Renderer not created'); const outputElement = new OutputHtml().getFirstOuputElement(); await renderer!.renderOutputItem(createOutputItem('content', stdoutMimeType), outputElement); const handlerCount = settingsChangedHandlers.length; await renderer!.renderOutputItem(createOutputItem('content', stdoutMimeType), outputElement); assert.equal(settingsChangedHandlers.length, handlerCount); }); </ins> });

Discussion:
a cell with enough output to truncate scroll the link to view as a scrollable element :bug: output height is stretched to show entire output without scrollable region
Change:
name: localize('status.editor.screenReaderMode', "Screen Reader Mode"), text, ariaLabel: text, <del> command: 'showEditorScreenReaderNotification', </del> kind: 'prominent' }, 'status.editor.screenReaderMode', StatusbarAlignment.RIGHT, 100.6); }

Discussion:
We should not prompt IMO anymore since we detect the screen reader.
let's discuss this on Monday
I like the idea, but I suggest that we leave the prompt for at least one more milestone. After that, we can compare the number of accessibility users we have after changes and see how precise the detection is. We might also see that the detection is more precise on some platforms, in which case we can leave the prompt only for some platforms. Does that make sense? What do you think? fyi who introduced the prompt initially
Safe to remove now?
I suggest to leave it on for at least one more milestone since our accessibility detection got off. I will assign it to March for now. Hope that is ok.
Thanks for fixing this. I just assigned to October and verification-needed. I think the verify steps are the following: On Windows turn on NVDA VS Code insiders (have no settings set). an editor, type some text sure NVDA reads this text as you navigate through it character by character Same on macOS with VoiceOver.
I haven't heard user complaints, so let's just keep this
Change:
"libgcc_s.so.1", "libgcc_s.so.1(GCC_4.0.0)", "libgcc_s.so.1(GLIBC_2.0)", <del> "libgconf-2.so.4", </del> "libgdk-x11-2.0.so.0", "libgdk_pixbuf-2.0.so.0", "libgio-2.0.so.0",

Discussion:
Afaik, electron should build with dconf instead of gconf.
See also
Please report here:
electron now (3.x) works without gconf. All you have to do is
I can confirm that Insiders 1.31 works without gconf. Can gconf be dropped for insiders?
Change:
private _ignoreChangeEvent: boolean = false; private _data: Record<string, string[] | undefined>; <ins> private _hiddenByDefaultCache = new Map<string, boolean>(); </ins> constructor(@IStorageService private readonly _storageService: IStorageService) { try { const raw = _storageService.get(PersistedMenuHideState._key, StorageScope.PROFILE, '{}');

Discussion:
Type: <bBug</bIn the most recent insiders, opening the command palette seems to take around a second: ! There is also a large delay when filtering VS Code version: Code - Insiders 1.75.0-insider (Universal) (, 2023-01-11T16:46:25.875Z) OS version: Darwin x64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
All the little calls at the bottom of the chart are to Possibly caused by
Confirmed that this does seem caused by In main right now, it is slow but not as painfully slow: ! After a revert though it becomes very fast: !
Change:
import { StandardKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { KeyCode } from 'vs/base/common/keyCodes'; import { ContextScopedHistoryInputBox } from 'vs/platform/browser/contextScopedHistoryWidget'; <del> import { attachInputBoxStyler } from 'vs/platform/theme/common/styler'; </del> <ins> import { attachInputBoxStyler, attachStylerCallback } from 'vs/platform/theme/common/styler'; </ins> import { IThemeService } from 'vs/platform/theme/common/themeService'; <ins> import { badgeBackground, badgeForeground, contrastBorder } from 'vs/platform/theme/common/colorRegistry'; </ins> import { ReplEvaluationResult, ReplEvaluationInput } from 'vs/workbench/contrib/debug/common/replModel'; <ins> import { localize } from 'vs/nls'; </ins> type ParsedQuery = {

Discussion:
Testing Just another feature request. It would be useful to see how many debug console items are filtered out. Especially if I see this number going up, then I know I am missing new messages.
Yeah great idea. I think this could be shown in the filter area. This could be a shared experience also in the Problems view I am opening this up for PRs. Code pointer
FYI, problems view already show this like below <img width="458" alt="image" src="https://user-"
Great! Then we should just copy what Problems is doing Assigning to September so I tackle then if no PR's arrive
Hi I can take a look into this if no one else is assigned.
sounds great. We should just have the exact same functionality as the Problems view, so checking how it is done there is a good start.
friendly ping regarding this, since if you are not looking into it I might take a look next week...
Hi sorry, I didn't have time last week. I've just started looking into the issue. I hope to have something ready for next week if it's ok with you. I'll keep you updated. Thanks.
great thanks. Since you are already on this I will remove the label
Thanks to we now have this. Adding verification needed so we get this verified: Start debugging and verify when using the debug filter that the filter shows what is the number of hidden items
Change:
*--------------------------------------------------------------------------------------------*/ import { addDisposableListener } from 'vs/base/browser/dom'; <del> import { alert } from 'vs/base/browser/ui/aria/aria'; </del> <ins> import { alert, status } from 'vs/base/browser/ui/aria/aria'; </ins> import { mainWindow } from 'vs/base/browser/window'; import { Emitter, Event } from 'vs/base/common/event'; import { Disposable } from 'vs/base/common/lifecycle';

Discussion:
Testing While testing I noticed that when I moved my cursor on a line with an error, the word was read, but the contents of that line were no longer read. I was wondering if this is intended? I noticed that sometimes the beginning of the text on the line is read, before it breaks off and reads the alerts.
I noticed that sometimes when I put my cursor on a line with a breakpoint, it does not read the word . Is the alert only supposed to sound at specific moments? Ie, for example the first time the cursor is placed on an active line with a breakpoint?
alerts interrupt whatever else might be read by design. And yes, it looks like in your case, you're using mouse clicks vs arrow keys to navigate between the lines. We listen to arrow keys, thus it's expected that you wouldn't hear the cues.
Additionally, I have checked with our power SR users and the alerts are working as expected in the editor.
I am going to open an issue to get more feedback on this.
Hi thank you for the clarification, that makes sense.
We are going to use instead here because editor content is the priority.
Change:
collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .monaco-list-row > .cell-inner-container { padding-top: ${CELL_TOP_MARGIN}px; }`); collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .cell-inner-container { padding-bottom: ${MARKDOWN_CELL_BOTTOM_MARGIN}px; padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .cell-inner-container.webview-backed-markdown-cell { padding: 0; }`); <del> collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .webview-backed-markdown-cell.markdown-cell-edit-mode .cell.code { padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); </del> <ins> collector.addRule(`.notebookOverlay .cell-list-container > .monaco-list > .monaco-scrollable-element > .monaco-list-rows > .markdown-cell-row > .webview-backed-markdown-cell.markdown-cell-edit-mode .cell.code { padding-bottom: ${MARKDOWN_CELL_BOTTOM_MARGIN}px; padding-top: ${MARKDOWN_CELL_TOP_MARGIN}px; }`); </ins> collector.addRule(`.notebookOverlay .output { margin: 0px ${CELL_RIGHT_MARGIN}px 0px ${CODE_CELL_LEFT_MARGIN + CELL_RUN_GUTTER}px; }`); collector.addRule(`.notebookOverlay .output { width: calc(100% - ${CODE_CELL_LEFT_MARGIN + CELL_RUN_GUTTER + CELL_RIGHT_MARGIN}px); }`);

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. --- VS Code Version: 1.56.0-insider OS Version: Windows 10 Steps to Reproduce: new blank notebook cells only are missing bottom padding: ! <!-- 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. --