jiebi/CodeConvo huggingface dataset:
Code change:
], "extensions": [ ".gitignore_global", <del> ".gitignore" </del> <ins> ".gitignore", ".git-blame-ignore-revs" </ins> ], "configuration": "./languages/ignore.language-configuration.json" }

Related discussion:
text: <!-- 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. --Currently, it is treated as . (I have disabled all my extensions and confirm this behavior) It does support as comment like does. A simple workaround now is to set But it's nice to have it built in supported.
Clone the repository Open the repository in VS Code Insiders Rename to Open the file: Confirm that the file type is detected as "Ignore" Confirm that the comments in the file are coloured correctly
Code change:
if (searchView) { const viewer = searchView.getControl(); const selected = viewer.getFocus()[0]; <del> await viewer.expand(selected, true); </del> <ins> await forcedExpandRecursively(viewer, selected); </ins> } }

Related discussion:
text: to search, then click the that expands the results. :bug: does not expand. Looking into this more, it is because the call for the node isn't working.
I've also seen the same thing with not working. Unsure if this is related, but the repro is the same, but between step 2 and 3, expand the AI results.
This seems to also happen in when in tree mode.
It could be very expensive if expand all would actually expand all tree nodes in an async data tree. It's possible to have infinite deep async trees so in those cases this method would crash. My recommendation would be to create your own implementation for this in the search view. If that does not work the way you would like it to, we could consider alternatives. I think the bulk edit pane has a similar behaviour here:
Code change:
return this._scrollBeyondLastLine && !this.isEmbedded; } <del> layout(dimension: DOM.Dimension, shadowElement?: HTMLElement, position?: DOM.IDomPosition): void { </del> <ins> layout(dimension: DOM.Dimension, shadowElement?: HTMLElement, _position?: DOM.IDomPosition): void { </ins> if (!shadowElement && this._shadowElementViewInfo === null) { this._dimension = dimension; return;

Related discussion:
text: I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps
Code change:
/** * A chat request handler is a callback that will be invoked when a request is made to a chat participant. */ <del> export type ChatRequestHandler = (request: ChatRequest, context: ChatContext, response: ChatResponseStream, token: CancellationToken) => ProviderResult<ChatResult>; </del> <ins> export type ChatRequestHandler = (request: ChatRequest, context: ChatContext, response: ChatResponseStream, token: CancellationToken) => ProviderResult<ChatResult | void>; </ins> /** * A chat participant can be invoked by the user in a chat session, using the `@` prefix. When it is invoked, it handles the chat request and is solely

Related discussion:
text: Testing If there's no error case, I now need to return something like:
Hi we have branched off from today, so I am pinging about the milestone here. Would you like to make this issue a candidate or move it out to the milestone?
Moving to March for now. Feel free to move this issue back to February if it turns out to be a candidate.
It's already a , which allows 'undefined' but not void. Is it weird to say ?
+1 on this, I have to explicitly today
Code change:
override prepareLayout(): void { if (this.currentElement?.cellKind === CellKind.Code && this._commentThreadWidget) { <del> this.currentElement.commentHeight = dom.getClientArea(this._commentThreadWidget.container).height; </del> <ins> this.currentElement.commentHeight = this._calculateCommentThreadHeight(this._commentThreadWidget.getDimensions().height); </ins> } }

Related discussion:
text: have an eager comments controller extension (see below) open a notebook create a new cell leak warnings are printed
This seems to be rooted at  It looks like a new is created without always disposing the old one. The looks highly suspicious. <img width="1586" alt="Screenshot 2022-10-26 at 14 09 41" src="https://user-"
Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening
thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.
Thanks
Code change:
"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.60", "xterm-addon-search": "0.9.0-beta.39", "xterm-addon-serialize": "0.7.0-beta.13", </del> <ins> "xterm": "4.19.0-beta.67", "xterm-addon-search": "0.9.0-beta.41", "xterm-addon-serialize": "0.7.0-beta.15", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.41", "xterm-headless": "4.19.0-beta.60", </del> <ins> "xterm-addon-webgl": "0.12.0-beta.43", "xterm-headless": "4.19.0-beta.67", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Related discussion:
text: https://user-
Related ,
happening bc the first line's marker isn't disposed of (and thus the decoration isn't either) !
so maybe we should have some API on xterm like so that can be handled specially?
oh here's the issue that solved but looks like that actually wasn't solved anyway
Just to confirm, to verify this issue, are you typing commands followed by the clear command in between? Or are you clearing the terminal another way?
Typing and clearing
Pretty sure this is the command, not run in the terminal
Code change:
"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.60", "xterm-addon-search": "0.9.0-beta.39", "xterm-addon-serialize": "0.7.0-beta.13", </del> <ins> "xterm": "4.19.0-beta.67", "xterm-addon-search": "0.9.0-beta.41", "xterm-addon-serialize": "0.7.0-beta.15", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.41", "xterm-headless": "4.19.0-beta.60", </del> <ins> "xterm-addon-webgl": "0.12.0-beta.43", "xterm-headless": "4.19.0-beta.67", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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: 1.50.1 OS Version: 10.15.7 Steps to Reproduce: system input source to shuangpin, before which add shuangpin as an input source. ! caps lock, with caps lock unlock, you will input Chinese character, which is an expected behavior. something in the integrated terminal, I can only input upper case letters. But when I input something in editor or some other application, I can input lower case letters. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes. Actually I think it might be the problem of might decide the letters by cap lock. This is not as expected with shuangpin mode.
This looks like an upstream issue in
Thanks for replying. Opened an issue for
Code change:
} this.focus(); <ins> this._onWillPaste.fire(currentText); </ins> this.xterm.raw.paste(currentText); <ins> this._onDidPaste.fire(currentText); </ins> } async sendText(text: string, shouldExecute: boolean, bracketedPasteMode?: boolean): Promise<void> {

Related discussion:
text: Steps to Reproduce: text into PowerShell (with Terminal suggest enabled) see batched pasting behavior
maybe related to
Haha, I think this is it triggering completions while the pasted text is being send then kicking in. Pastes should never trigger completions so let's track that here.
When verifying make sure you're on macOS.
Code change:
this._editorWidget.updateOptions({ ariaLabel: provider.options.ariaLabel }); this._editorWidget.focus(); }); <del> return toDisposable(() => provider.onClose()); </del> <ins> return toDisposable(() => { }); </ins> } private _layout(): void {

Related discussion:
text: run voice over open terminal start accessibility help via while it start reading select :bug: the reading continues all way to the end
I'm not sure we can / should prevent this from happening. Screen reader users have a way to abort the reading of certain contents. or might have insight here
This is very strange. The behavior is as if Voiceover wasn't detecting the change of context. In other words, upon pressing Escape, Voiceover is not detecting that focus is moving from one control to a different one. This is often related to focus events that are not happening. I have a question. Is the terminal accessible help somehow being removed from the DOM or hidden from accessibility without removing focus first? When debugging with NVDA, the first thing that happens after pressing Escape is an exception, as if the screen reader had lost access to something that should be there (DEBUGWARNING - NVDAObjects.IAccessible.IAccessible.getIAccessibleRole (15:05:00.655) - MainThread (5320): accRole failed: (-, 'Unspecified error', (None, None, None, 0, None)) ). Voiceover not stopping upon closing the accessibility help not only happens in the terminal. It also happens in the editor, the copilot chat and anywhere we call the accessibility help. Another thing I have observed is that, if I press f1 from the editor, I hear the name terminal accessibility help even though the terminal is not in focus and the content is related to the editor. This happens in both Windows and macOs. Finally, I have also observed that the command Open accessibility help doesn't show up in the command palette on the mac side for me, although pressing Option +F1 opens it.
Thanks for your findings You hear terminal accessibility help because I accidentally had that as the aria label. Fixed here I will comment on the others in a bit
This wasn't showing up there 2 days ago - are you on the latest insider's?
accRole failed: (-, 'Unspecified error', (None, None, None, 0, None)) Yep, we were closing the context view before calling , which is the function that focuses the other element. Will fix
Hm, that didn't fix it. What fixes it is after pressing escape, moving my cursor in the editor.
Code change:
this._editorWidget.updateOptions({ ariaLabel: provider.options.ariaLabel }); this._editorWidget.focus(); }); <del> return toDisposable(() => provider.onClose()); </del> <ins> return toDisposable(() => { }); </ins> } private _layout(): void {

Related discussion:
text: is correct though
It says you are currently on a application, inside of web content. When the editor is focused. !
Right. From the VO perspective, VS Code is a website.
Hovers use the context view service as well - they handle this correctly though when escape is used. that is done here. we probably need something similar
I clearly had not updated when I thought I had done so. I'm in the latest now and the command is showing up.
Great, thanks for the debugging. This issue should be fixed shortly.
That didn't work either, going to keep trying.
Ok so hiding the context view sets to and the element's display to . but for some reason, the screen reader continues to focus on that
Figured something out - when I use , then it works. So this is a timing issue
This seemed to work correctly for me... though my ESC button is a part of the touchbar so I have to do extra steps when VoiceOver is on to actually trigger ESC.
Code change:
private readonly disposables: Disposable[] = []; constructor(private readonly repository: Repository) { <del> this.disposables.push(window.registerFileDecorationProvider(this)); repository.historyProvider.onDidChangeCurrentHistoryItemGroup(this.onDidChangeCurrentHistoryItemGroup, this, this.disposables); </del> <ins> this.disposables.push( window.registerFileDecorationProvider(this), runAndSubscribeEvent(repository.historyProvider.onDidChangeCurrentHistoryItemGroup, () => this.onDidChangeCurrentHistoryItemGroup()) ); </ins> } private async onDidChangeCurrentHistoryItemGroup(): Promise<void> {

Related discussion:
text: Testing When turning off , the decorations disappear. When turning back on, they do not reappear automatically. !
Code change:
@IExplorerService explorerService: IExplorerService, @IUriIdentityService uriIdentityService: IUriIdentityService, @IProductService private readonly productService: IProductService, <del> @IPathService pathService: IPathService </del> <ins> @IPathService pathService: IPathService, @IConfigurationService configurationService: IConfigurationService, </ins> ) { <del> super(telemetryService, fileService, paneCompositeService, instantiationService, contextService, storageService, textResourceConfigurationService, editorService, themeService, editorGroupService, textFileService, explorerService, uriIdentityService, pathService); </del> <ins> super(telemetryService, fileService, paneCompositeService, instantiationService, contextService, storageService, textResourceConfigurationService, editorService, themeService, editorGroupService, textFileService, explorerService, uriIdentityService, pathService, configurationService); </ins> } protected override handleSetInputError(error: Error, input: FileEditorInput, options: ITextEditorOptions | undefined): Promise<void> {

Related discussion:
text: We don't want to officially have the hex editor be recommended for non-textual files, but what about a setting like that can be used to open a binary file in a given editor instead of showing the "binary file" message? ! I would love it if I could have all non-text files automatically opened in the hex editor.
To verify ensure the setting works as expected. Setting it to a custom editor should automatically have that editor be opened when a file is detected as binary.
Code change:
setGroup(group: IEditorGroup | undefined) { this._group = group; <ins> if (group?.scopedContextKeyService) { this._terminalInstance?.setParentContextKeyService(group.scopedContextKeyService); } </ins> } get group(): IEditorGroup | undefined {

Related discussion:
text: Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) 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 --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.
Code change:
setGroup(group: IEditorGroup | undefined) { this._group = group; <ins> if (group?.scopedContextKeyService) { this._terminalInstance?.setParentContextKeyService(group.scopedContextKeyService); } </ins> } get group(): IEditorGroup | undefined {

Related discussion:
text: I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- 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, but while confirming the fix I noticed more issues with these context keys
Code change:
this._register(dom.addStandardDisposableListener(this._contentDomNode.domNode, 'keydown', (e) => { if (e.keyCode === KeyCode.Escape) { this.hide(); <ins> instance.focus(); </ins> } })); this._register(instance.onDidFocus(() => this.hide()));

Related discussion:
text: Type: <bBug</bCC CC I create a terminal in VSCode, press shift+alt+f1 to display the accessibility help, and then press the esc key to dismiss the displayed information. I believe that the focus should be moved back to the terminal but it doesn't. I need to press shift+tab to move the focus back to the terminal. I tested using orca but I believe the same happens using nvda, I'll test later. VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-09T05:23:03.109Z) OS version: Linux x64 6.1.9-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (37)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.5.9 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.23.3 csharp1.25.4 vscode-kubernetes-tools1.3.11 remote-containers0.278.0 remote-ssh0.97. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.1 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.0 remote-explorer0.3. vsliveshare1.0.5828 fabric8-analytics0.3.6 java1.15. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.14.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.48.0 vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.37. vscode-maven0.40.
Code change:
this._register(dom.addStandardDisposableListener(this._contentDomNode.domNode, 'keydown', (e) => { if (e.keyCode === KeyCode.Escape) { this.hide(); <ins> instance.focus(); </ins> } })); this._register(instance.onDidFocus(() => this.hide()));

Related discussion:
text: vscode-spring-boot-dashboard0.10.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --