jiebi/CodeConvo huggingface dataset:
Change:
task.catch(err => { this._logService.error('[CHAT] extension request ERRORED', err, extension.value, requestId); <ins> throw err; </ins> }).finally(() => { this._logService.debug('[CHAT] extension request DONE', extension.value, requestId); });

Discussion:
Testing I asked a question and noticed this: ! Empty. Further inspection of my logs yielded: My participant is very straightforward: It throws on the: I was expecting to render in the chat
Currently, when there's an error, the stream is just going to be empty. But you can and that will be the actual failed promise with the error. Not sure if that's right or wrong, it looks like you can make the async iterable throw by calling on the , that might help for errors
Yeah, let's make sure to call but also know that this will be a generic error and that only the extension can make this graceful
This the stream and the result error, this is how my sample extension does it It's important to have for-await also inside try-catch
<!-- 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:
[![Build Status](https://vscode.visualstudio.com/_apis/public/build/definitions/a4cdce18-a05c-4bb8-9476-5d07e63bfd76/1/badge?branchName=master)](https://aka.ms/vscode-builds) [![Feature Requests](https://img.shields.io/github/issues/Microsoft/vscode/feature-request.svg)](https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Afeature-request+sort%3Areactions-%2B1-desc) [![Bugs](https://img.shields.io/github/issues/Microsoft/vscode/bug.svg)](https://github.com/Microsoft/vscode/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3Abug) <del> [![Gitter](https://img.shields.io/badge/chat-on%20gitter-blue.svg)](https://gitter.im/Microsoft/vscode) </del> <ins> [![Gitter](https://img.shields.io/badge/chat-on%20gitter-yellow.svg)](https://gitter.im/Microsoft/vscode) </ins> [VS Code](https://code.visualstudio.com) is a new type of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. Code

Discussion:
The color of Gitter badge doesn't align with the other badges which adds a bit of nonuniformity.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.553 --- <!-- score: 0.486 --- <!-- score: 0.482 --<!-- potentialduplicatescomment --
Change:
readonly resource: URI; readonly viewType: string; readonly notebook: INotebookTextModel | undefined; <ins> readonly hasErrorState: boolean; readonly hasConflictState: boolean; </ins> isResolved(): this is IResolvedNotebookEditorModel; isDirty(): boolean; isModified(): boolean;

Discussion:
Set auto save: afterDelay Edit a notebook See the dirty indicator briefly appear after editing
I guess this is
We never did that for custom editors because it requires code to ensure that an editor that is closed but pending to be saved via auto save is really waited upon on shutdown. To further explain: the behaviour is driven by method if you return from that method no dirty indicator will show up this means a user can close an editor with dirty changes as such, components have to ensure that the save continues in the background and even on shutdown Files implement this here: I think the reason we never adopted this for notebooks as that notebooks have a dual model: complex and simple. With simple (which is based on file working copies), we can probably implement this now similar to what files do, but it needs careful testing what happens when you close a notebook quickly enough before auto save finished.
We could revisit this once we remove complex notebook model and friends but the saving of notebooks is more complex than files and I wonder if it's worth it to implement this. Also the dirty indicator is also an indicator that saving is not done yet, which is valuable as saving notebooks is not necessarily instant. what do you think ?
I think it's ok to close if this is complicated. It's also a bit odd that if I edit and immediately close the tab, it asks me whether I want to save, when I've enabled autosave.
with your recent changes in and please take note of Specifically: being able to close an editor that is now not dirty because of auto-save may result in data loss if closing the editor disposes state that is needed for saving. Filed as planned for July. Nevertheless, I appreciate that you are willing to look into this issue
Change:
const scopesSeen = new Set<string>(); const sessionPromises = sessionData.map(async (session: SessionData) => { // For GitHub scope list, order doesn't matter so we immediately sort the scopes <del> const sortedScopes = session.scopes.sort(); const scopesStr = sortedScopes.join(' '); </del> <ins> const scopesStr = [...session.scopes].sort().join(' '); </ins> if (scopesSeen.has(scopesStr)) { return undefined; }

Discussion:
Issue Type: <bBug</bThe Avatar badge always shows <img width="351" alt="image (7)" src="https://user-"Clicking the action to authenticate doesn't dismiss it. VS Code version: Code - Insiders 1.68.0-insider (, 2022-05-20T05:16:17.334Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ vscode-eslint2.2.2 kusto0.3.8 gitlens-insiders2022.5.1705 prettier-vscode9.5.0 codespaces1.8.1 copilot1.22.5957 vscode-pull-request-github0.42.0 go0.33.0 vscode-language-pack-zh-hans1.68.0 python2022.7. vscode-pylance2022.5.2 jupyter2022.5. jupyter-keymap1.0.0 jupyter-renderers1.0.6 vscode-ai0.11. vscode-ai-remote0.13. remote-containers0.236.1 remote-ssh0.80.0 remote-ssh-edit0.80.0 remote-wsl0.66.3 azure-account0.10.1 hexeditor1.9.6 js-debug-nightly2022.5.1817 live-server0.2.12 vscode-github-issue-notebooks0.0.119 vscode-markdown-notebook0.0.26 vscode-selfhost-test-provider0.3.9 vsliveshare1.0.5561 vetur0.35.0 colab-keymap0.0.4 github-issue-notebook-enhancement0.0.1 vscode-code-renderer0.0.2 vscode-jupyter-checkpoint0.0.1 notification-tester2.5.1 rest-book6.0.1 tldraw-vscode1.13.3 shell-runner-notebooks0.0.2 luna-paint0.14.0 vscode-todo-highlight1.0.5 (3 theme extensions excluded) </details<!-- generated by issue reporter --
after reloading, does the go away?
Reloading fixes the issue for me
Change:
await terminalGroupService.showPanel(true); } } <ins> async function revealActiveTerminal(instance: ITerminalInstance, terminalEditorService: ITerminalEditorService, terminalGroupService: ITerminalGroupService): Promise<void> { if (instance.target === TerminalLocation.Editor) { await terminalEditorService.revealActiveEditor(); } else { await terminalGroupService.showPanel(); } } </ins>

Discussion:
Type: <bBug</bThis was working in the previous version, now when running lines of code from the editor with "key": "ctrl+enter", "command": "" The cursor automatically snaps to the terminal which is extremely annoying. Please fix this ASAP. VS Code version: Code 1.75.0 (, 2023-02-01T15:23:45.584Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.15.0-1031-azure <details<summaryExtensions (25)</summaryExtensionVersion ------ better-cpp-syntax1.17.2 jupyter-keymap1.0.0 vscode-ai-remote0.22.0 remote-containers0.275.0 remote-ssh0.96.0 remote-ssh-edit0.84.0 remote-wsl0.75.1 vscode-remote-extensionpack0.23.0 remote-explorer0.2.0 material-icon-theme4.23.1 vscode-kdb-q-forked1.2.2 unique-lines1.0.0 gitlens13.2.0 json-tools1.0.2 isort2022.8.0 python2023.2.0 vscode-pylance2023.2.10 jupyter2023.1. jupyter-keymap1.0.0 jupyter-renderers1.0.14 vscode-ai0.24.0 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 azure-account0.11.3 code-spell-checker2.16.0 (2 theme extensions excluded) </details<!-- generated by issue reporter --
Temporary work around is to use to refocus on editor 1, however that's not really effective for long periods of time.
in order to run text in the terminal, we need to focus it. this is working as designed
this wasn't the case on the previous version. You could execute lines of code from the editor with e.g. ctrl+enter without shifting focus to the terminal.

Here is a very simple example from the previous version I have on another machine: <img width="467" alt="image" src="https://user-"<img width="838" alt="image" src="https://user-"All 3 lines are executed with ctrl+enter, and focus does not shift to the terminal so I can e.g. move up/down and execute lines, type lines to execute on the fly. Please advise further as this was definately the behaviour in 1.74.3 and now broken in 1.75.0
ran into the same issue as you. Suspect you've already done this, but a quick fix is to add a new keybinding in with the multi-command extension installed:
Thank you so much for this workaround! If anyone else needs this, the extension is
This was caused by where it changed from just revealing to focusing
Thanks !
Hi, pls do we know when will be new release with this fix publicly available?
it will come in 1.76 which should get releases in about 3 weeks time.
Change:
{ "id": "javascriptreact", "aliases": [ <ins> "JavaScript JSX", </ins> "JavaScript React", "jsx" ],

Discussion:
The name "TypeScript React" nowadays is non-inclusive of all the libraries/frameworks out there that are built on JSX, but that are not React. React is not the only lib/framework that has JSX syntax! Let's make the field a fair play ground for all JSX libs. This is what I'm referring to: ! (it even shows React's logo) I'm writing an app with , for example. I'm not using React, and "TypeScript React" has no meaning in the context of a Solid app.
Other libs/frameworks include , , , etc.
Changing the display name is easy but we can't change the identifier. Also any new name should still mention react for the sake of all the documentation/tutorials out there that talk about . For example:
has the same issue. If I am in a project, it has nothing to do with React. Can there be a deprecated alias instead? For example, TypeScript JSX appears first, but someone can select (and maybe even it notifies them to prefer ?). It would be much better not to automatically teach people that JSX is React, because it isn't.
could be another friendlier option to alternatives.
I don't understand the association with ? Why not :roll_eyes: And I'm sure I missed some...
If there is a concern of keeping the UI consistent with existing (recent) content written about VS code, then why not treat the change as a depreciation of sorts? First change it to: Typescript JSX (previously Typescript React) Then with time docs can be updated to use the correct "Typescript JSX" and any community made docs/blogs could update as well. Then finally just remove the parentheses part completely when first party Docs are all confirmed updated to refer to it as "Typescript JSX". Even if it's not as direct of a fix, this still allows the root concern to be addressed and gives a nice path for it to happen.
I just wana say that the title is the best candidate for the change but not the identifier i.e . If you change that the whole community would break.
Just introduce an alias and deprecate it slowly in a 2-year frame or somewhat
Couldn't the identifier either: a) change over time the same I suggested the title, and/or b) have the old one kept as an alias?
Nope, identifier shouldn't have to change.

You are talking about the old tooling and others century old editors (i.e vim/neovim) that depends on the identifier to detect/set the file type.
How about a new language type with identifier and display name "TypeScript JSX" with the ts logo and clone of the existing grammar definitions. Set it's precedence in the list higher than . Then can be deprecated and eventually removed at some later date.
Change:
this.show(dto.revealLocation.range, TestingOutputPeek.lastHeightInLines || hintMessagePeekHeight(message)); this.editor.revealPositionNearTop(dto.revealLocation.range.getStartPosition(), ScrollType.Smooth); <del> this.editor.focus(); </del> return this.showInPlace(dto); }

Discussion:
The original issue comes from Comment from Looks like there is some problem with the editor focus when the test message view is peeked out?
I found a way to view test results and work with tests. When the tests are executed, I need to press CTRL+m for tab key to move between elements, then tab until the close button and after that panel with buttons to go to previous and next failure results there will be a tree with test results. That's accessible with NVDA, I am sure it's also accessible with Orca. Thank you for help all!
Thanks for the issue! at the moment we reveal the failed position and then focus the editor. Instead is it preferable to focus within the peek view like the references peeks do?
yeah, it would be better if you focus inside the peek automatically for accessibility reasons. If you want, you can also differentiate if the command is triggered via keybinding, if yes then move focus, otherwise do not. This is what the editor hover does. Though I think it might be a bit confusing in this case, so I suggest to just pass focus inside the peek.
Thank you for such an active feedback! I also think that it would be more convenient if the focus moves directly to the peek instead of moving it to the editor with the selected line that can be easily deleted by accedent. Thank 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!
how about some verification steps unless resurfaces?
Steps in the original post should still be accurate. Opening test peek output (for a failed test) via should focus and screen-read the peek view, rather than staying in the editor.
Change:
const treeInputArray = Array.isArray(treeInput) ? treeInput : Array.from(treeInput.children.values()); // Has collapsible root when anything is expanded this.viewHasSomeCollapsibleRootItem.set(hasExpandedNode(this.tree, treeInputArray)); <ins> // synchronize state to cache this.storeTreeViewState(); </ins> } override dispose(): void {

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. --For example when I open a project in v, I expand the folder on the file tree. When I refresh the whole page, the default behavior now is that the folders are collapsed, which means that I need to expand the folders one by one again the last time I opened them. !
If the expansion state of the file tree folder can remember the last expansion like tabs, similar to the gif below, I think this is a better effect. !
I have fixed this problem and will mention a pr later.
The reason for this problem is that there are multiple calls to the function during the rendering of the file tree. The state will be read from the cache for the first time, but before the execution is completed for the first time, the will be executed again. At this time, the tree already has a value. However, because the file tree data is not ready (because the data on the Web side is asynchronous), the state returned by the function is empty, resulting in the final file tree returning to the default collapsed state.
Change:
} await this.repository.commit(message, opts); <del> await this.commitOperationCleanup(message, opts); </del> <ins> await this.commitOperationCleanup(message, indexResources, workingGroupResources); </ins> }, () => this.commitOperationGetOptimisticResourceGroups(opts));

Discussion:
Type: <bBug</bI have the setting: "Git: Close Diff On Operation" enabled. Staging a change will close the diff. Committing a staged change will close the diff. But if I just click the Commit button, the changes will commit but the diff won't close. Reproduction steps: & save a file the file in "Source Control" to open a diff Commit Expected behavior: The "(Working Tree)" tab closes Actual behavior: It stays open VS Code version: Code 1.77.3 (Universal) (, 2023-04-12T09:19:37.325Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (22)</summaryExtensionVersion ------ tailwind-documentation0.1.6 ng-template15.2.1 tailwind-docs2.0.0 docs-view0.0.11 vscode-tailwindcss0.9.11 language-postcss1.1.0 vscode-deno3.17.0 vscode-axe-linter4.7.0 nasc-touchbar1.12.0 copilot1.84.51 vscode-test-explorer2.21.1 tasks-statusbar0.1.0 git-graph1.30.0 dotenv1.0.1 csharp1.25.4 test-adapter-converter0.1.7 vsliveshare1.0.5864 vscode-yaml1.12.2 snyk-vulnerability-scanner1.18.2 code-spell-checker2.20.4 vscode-todo-highlight1.0.5 pretty-ts-errors0.4.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Change:
openerService.open(link, { fromUserGesture: true }); })); <del> this._register(this.webview.onDidWheel(e => { this.notebookEditor.triggerScroll(e); })); </del> this._register(this.webview.onMessage((data: IMessage) => { if (data.__vscode_notebook_message) { if (data.type === 'dimension') {

Discussion:
Issue Type: <bFeature Request</bCurrently it's unclear and difficult to handle scrolling events inside an output which is rendered in the webview due to the disadvantage of our current architecture: we listen to event in the webview and scroll the list view in the main thread accordingly. It means if users attempt to scroll in a native scrollable element, the element will be scrolled in the webview, and also trigger the whole editor to scroll. Events triggered when users scroll on a scrollable element events come right after events, usually in a few milliseconds. If users trigger scroll (by mouse wheel or touchpad) on a non-scrollable element, there are only events. For our scenario, we want to emit events to the main thread, only when there is no event followed right after. This can be archived by delaying the wheel event message to the main thread The catch of this solution is how long should we delay. Usually a scroll event comes after a wheel event in just a few ms but it's not guaranteed. Renderers handle the scrolling themselves. For example, a renderer can stop sending event on a scrollable element. The challenge for renderers is they need to be keep track of any element with it renders and stop events only when necessary. VS Code version: Code - Insiders 1.44.0-insider (, 2020-03-27T05:28:16.333Z) OS version: Darwin x64 19.2.0 <!-- generated by issue reporter --
cc as you mentioned that it would be painful to write a list view in the output.
I would suggest listening to the wheel event, and triggering a scroll in the notebook if there's no parent element that will scroll. You should be able to tell that with something like
thanks very much, the suggestion is pretty solid. ! The only update to 's snippet above is the scroll should stop at the container of each output container instead of going all the way up to body (potentially). The event listener should also then be registered only in notebook webview other than all webviews.
Change:
} static fromEmmet(template: string): CodeSnippet { <del> return EmmetSnippetParser.parse(template); </del> <ins> let matchFinalStops = template.match(/${0}|$0/g); if (!matchFinalStops || matchFinalStops.length === 1) { return CodeSnippet.fromTextmate(template); } // Emmet sometimes returns snippets with multiple ${0} // In such cases, replace ${0} with incremental tab stops const snippetMarkers: Marker[] = new SnippetParser(true, false).parse(template) || []; let getMaxTabStop = (markers: Marker[]): number => { let currentMaxTabStop = -1; markers.forEach(marker => { if (marker instanceof Placeholder && /^d+$/.test(marker['name'])) { let currentTabStop = Number(marker['name']); let nestedMaxTabStop = getMaxTabStop(marker['defaultValue'] || []); currentMaxTabStop = Math.max(currentMaxTabStop, currentTabStop, nestedMaxTabStop); } }); return currentMaxTabStop; }; let maxTabStop = getMaxTabStop(snippetMarkers); let setNextTabStop = (markers: Marker[]) => { markers.forEach(marker => { if (marker instanceof Placeholder) { if (marker['name'] === '0') { marker['name'] = ++maxTabStop + ''; } setNextTabStop(marker['defaultValue'] || []); } }); }; setNextTabStop(snippetMarkers); const snippet = new CodeSnippet(); _fillCodeSnippetFromMarker(snippet, snippetMarkers); return snippet; </ins> } public lines: string[] = [];

Discussion:
Test item VSCode Version: Code - Insiders 1.9.0-insider (, 2017-01-24T10:29:13.076Z) OS Version: Darwin x64 15.6.0 Extensions: None Steps to Reproduce: with: after in some size : : Same goes for single line expansions, although there it is not as bad because it is just one arrow-left key to correct.
Another CSS example is . Pressing when done should land the caret at the end of the line.
This is due to the way snippets get expanded. Take the below example of a snippet When you use the above in any file and after you enter the placeholder followed by ENTER, the cursor remains where the entry was made and does not go to end of line Is there any way to get the cursor to the end of the snippet after completion?
Yes, is the final cursor position which default to the end of the snippet. The sample above it is used to place the cursor elsewhere. Changing above to should do it.
! So the being the final cursor position is a standard behavior for snippets in general or is this VS Code specific rule? The reason I ask is, in order to fix this bug if I make an update to then I wonder if I will be breaking any other editor that uses emmet If it is vscode specific, then I'll make the fix on our end
That's a good question. It is default Textmate behaviour but I don't know if emmet is also Textmate...
emmet does borrow from text mate
Very cool!
Change:
"test-extension": "vscode-test", "preinstall": "node build/npm/preinstall.js", "postinstall": "node build/npm/postinstall.js", <del> "compile": "node --max_old_space_size=4095 ./node_modules/gulp/bin/gulp.js compile", </del> <ins> "compile": "node --max-old-space-size=4095 ./node_modules/gulp/bin/gulp.js compile", </ins> "watch": "npm-run-all -lp watch-client watch-extensions", "watchd": "deemon yarn watch", "watch-webd": "deemon yarn watch-web",

Discussion:
Builds:
fyi
Attempting a fix by simply doubling the max memory available to V8.
Again in
Then I'm out of ideas. we might need to split all those mangling tasks into independent processes, if memory limits are being hit.
Are we sure that we are on the right track here? According to my counting (below) we have only a tenth of the code in extensions (compare to the src-folder) so I wonder why mangling would eat up so much memory here?
I am not sure OOM is the symptom here actually, just my best hunch, but it seems is indeed the problem: <img width="913" alt="image" src=""
Added a every 1 second log of memory usage to this task: Build running:
Created to log the memory usage after each mangling step
lol - similar idea here:
I think we are on to something here. The memory is growing a lot, maybe some state leaks when mangling the next extension. Each extension is its own tsconfig and mangling context. This shouldn't pile up but memory should be released inbetween
Can you take a look at this? I put my money on this which keeps its mangler around. Looks like we need some webpack hook to dispose that loader
I gave it a stab at for which I have confidence, running locally shows how memory is growing and shrinking! This isn't a webpack change but just some cleanup in the mangler itself
!