jiebi/CodeConvo huggingface dataset:
Change:
}); port.addEventListener('message', msg => { <del> globalThis.dispatchEvent(new MessageEvent('message', { data: msg.data })); </del> <ins> globalThis.dispatchEvent(new MessageEvent('message', { data: msg.data, ports: msg.ports ? [...msg.ports] : undefined })); </ins> }); port.start();

Discussion:
use safari open open TS initialises forever, console shows the error below
After , this now works fine in Safari tech preview. I suspect there's an issue with our nested worker polyfil but am still looking into this
I've tried debugging what is going on here but can't figure it out (and safari's dev tools are certainly not helping) What I suspect is that our nested worker polyfill causes a message to be dropped somewhere, possibly because a message port is started early or never started Given that everything works in safari tech preview though and given that don't plan on shipping project wide intellisense until cross origin isolation is enabled, this is a lower priority. Un-assigning from this month
I believe this all works in Safari 16.4 which nested worker support. Not sure what the issue was with our nested worker polyfill (note that needs to be merged too to see this working end to end)
Change:
templateData.repliesMetadata.container.style.display = ''; templateData.repliesMetadata.count.textContent = this.getCountString(commentCount); <del> templateData.repliesMetadata.lastReplyDetail.textContent = nls.localize('lastReplyFrom', "Last reply from {0}", node.element.replies[node.element.replies.length - 1].comment.userName); templateData.repliesMetadata.timestamp.setTimestamp(originalComment.comment.timestamp ? new Date(originalComment.comment.timestamp) : undefined); </del> <ins> const lastComment = node.element.replies[node.element.replies.length - 1].comment; templateData.repliesMetadata.lastReplyDetail.textContent = nls.localize('lastReplyFrom', "Last reply from {0}", lastComment.userName); templateData.repliesMetadata.timestamp.setTimestamp(lastComment.timestamp ? new Date(lastComment.timestamp) : undefined); </ins> } private getCommentThreadWidgetStateColor(state: CommentThreadState | undefined, theme: IColorTheme): Color | undefined {

Discussion:
In the comments overview, the date of the last reply is wrong. It looks like it took the date of the first comment: ! (cc
I have a fix for this, I'll send a PR.
Change:
Dom.addClass(error, 'task-statusbar-item-label-counter'); error.innerHTML = '0'; <ins> error.title = errorIcon.title = errorTitle(0); </ins> label.appendChild(error); Dom.addClass(warningIcon, 'task-statusbar-item-label-warning');

Discussion:
Issue Type: <bFeature Request</bVSCode uses different conventions for the problem counters in the problems view and in the status bar. The problems view displays: 1 2 ... 999 1K 2K ... 10K+ and the tooltip shows the actual number. The status bar displays: for errors/warnings: 1 2 ... 99+ and the tooltip doesn't show the actual number. for infos: 1 2 ... (always the actual number), the tooltip doesn't show the actual number. <img width="118" alt="problems-view" src="https://user-"<img width="108" alt="status-bar" src="https://user-"VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.4.0 <!-- generated by issue reporter --
assigning to you. I personally would adopt the status bar to the problems view. Everything over 99 is not very informative anyways.
Change:
"@vscode/l10n-dev": "0.0.30", "@vscode/telemetry-extractor": "^1.10.2", "@vscode/test-cli": "^0.0.3", <del> "@vscode/test-electron": "^2.3.5", </del> <ins> "@vscode/test-electron": "^2.3.8", </ins> "@vscode/test-web": "^0.0.42", "@vscode/v8-heap-parser": "^0.1.0", "@vscode/vscode-perf": "^0.0.14",

Discussion:
See
I have not seen this before and I suspect an unhealthy CI, the log indicates a successful download to me: Code is here: I am using VS Code test module , so moving to
also indicates a broken stable download. Maybe this was just unlucky timing with us releasing a new version?
cc in case this is CDN related.
We need to bump to 2.3.8:
Change:
import * as strings from 'vs/base/common/strings'; import { Range } from 'vs/editor/common/core/range'; import * as editorCommon from 'vs/editor/common/editorCommon'; <del> import * as collections from 'vs/base/common/collections'; </del> import { Marker, Variable, Placeholder, Text, SnippetParser } from 'vs/editor/contrib/snippet/common/snippetParser'; export interface IIndentationNormalizer {

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:
import { DynamicEditorConfigurations } from 'vs/workbench/browser/parts/editor/editorConfiguration'; import { EditorActionsDefaultAction, EditorActionsTitleBarAction, HideEditorActionsAction, HideEditorTabsAction, ShowMultipleEditorTabsAction, ShowSingleEditorTabAction } from 'vs/workbench/browser/actions/layoutActions'; import { ICommandAction } from 'vs/platform/action/common/action'; <ins> import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; </ins> //#region Editor Registrations

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. --Please disable the "Previous Change," "Next Change," and similar buttons in the diff view when there are no differences (both files are equal). This would be a swift way to ensure that no differences exist, especially when cheking between local and remote files. Such clarity can be crucial in certain situations. On the right side, it's also possible to observe the differences on the "file map." However, at times, this map might be cluttered with additional markings, such as code warnings, which can lead to confusion. Typically, I find myself clicking the "Next Change" button when I need to verify the presence of differences. If the file doesn't scroll, I can be confident that none exist. Yet, this workaround is unnecessary. Furthermore, adhering to good UX practices involves displaying buttons as disabled when they lack any action. !
When you are scrolled away from the single diff in a file, you can use these buttons to scroll back again to the diff. If there buttons would be disabled, this does not work anymore. Maybe the feature "Toggle Collapse Unchanged Lines" might help you.
If there are no differences (both files are equal) the buttons are useless (there is no diff to scroll to) and should be disabled to follow good UI practices. Edit: I improved the issue description.
!
Change:
] } }); <del> storageService.store(REMOTE_TUNNEL_USED_STORAGE_KEY, connectionInfo.hostName, StorageScope.APPLICATION, StorageTarget.USER); </del> <ins> const usedOnHostMessage: UsedOnHostMessage = { hostName: connectionInfo.hostName, timeStamp: new Date().getTime() }; storageService.store(REMOTE_TUNNEL_USED_STORAGE_KEY, JSON.stringify(usedOnHostMessage), StorageScope.APPLICATION, StorageTarget.USER); </ins> } else { await notificationService.notify({ severity: Severity.Info,

Discussion:
I switched from a testing profile to my default profile on my Windows machine, and got a message that my macOS machine turned on remote access, even though it's not even on. !
I didn't think of that, good catch. I use settings sync as a communication channel to learn about other machines connecting to a tunnel. I guess I need to add a timestamp as well.
Change:
this._sourceControl.inputBox.validateInput = this.validateInput.bind(this); this.disposables.push(this._sourceControl); <del> this._mergeGroup = this._sourceControl.createResourceGroup('merge', localize('merge changes', "Merge Changes")); this._indexGroup = this._sourceControl.createResourceGroup('index', localize('staged changes', "Staged Changes")); this._workingTreeGroup = this._sourceControl.createResourceGroup('workingTree', localize('changes', "Changes")); </del> <ins> this._mergeGroup = this._sourceControl.createResourceGroup('merge', localize('merge changes', "MERGE CHANGES")); this._indexGroup = this._sourceControl.createResourceGroup('index', localize('staged changes', "STAGED CHANGES")); this._workingTreeGroup = this._sourceControl.createResourceGroup('workingTree', localize('changes', "CHANGES")); </ins> const updateIndexGroupVisibility = () => { const config = workspace.getConfiguration('git', root);

Discussion:
Issue Type: <bBug</bWe are developing an extension that implements a source control provider. It successfully adds s to its section. However the standard themes display the group captions in UPPERCASE by styling them with For our use case it's important to show the group captions in their actual case. AFAIK there isn't a way for our extension to make that happen. VS Code version: Code 1.34.0 (, 2019-05-15T21:59:37.030Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Yeah... let's then change the casing style and just uppercase them on the Git extension directly.
, Removing the styling , is that it or I should add it somewhere ? Because you said
Yeah we want to keep the git extension section as , etc.
, Could not find the exact detail of what to remove. Removing the style will remove it in all places , so that is not correct. I dont understand what group captions actually mean ( CC : , if you could help ) I found there are these ResourceGroup () for which the style is applied. Please help me out with this on the correct approach.
I think proposes that you do remove that style, but that you also change the code to explicitly uppercase the localized captions of the the three items being created there. With those changes Git users won't see any change of behaviour, but other SCM extensions can set mixed-case captions and have them display to the end user.
, Sorry got confused with the group captions , Sent a PR to fix this !
I'd love to see your PR get merged, but for some reason I don't understand it apparently failed in the Windows part of Azure Pipelines. can you help get this moving?
The windows build error might be some random errors , Happened in one more PR ( ) I guess that is not an issue and should confirm that.
Is there some way you can resubmit your PR to the build pipeline? Maybe it will pass the second time. Or if it doesn't perhaps there will be more info in the log.
Change:
setupSearchTests(logger); setupNotebookTests(logger); setupLanguagesTests(logger); <del> if (opts.web) { setupTerminalTests(logger); } // Not stable on desktop/remote https://github.com/microsoft/vscode/issues/146811 </del> <ins> setupTerminalTests(logger); </ins> setupTaskTests(logger); setupStatusbarTests(logger); if (quality !== Quality.Dev && quality !== Quality.OSS) { setupExtensionTests(logger); }

Discussion:
With support for for Electron tests, we should enable terminal tests: I eagerly had enabled them but since we don't know whether Electron smoke tests with are stable, I moved back to only running them in web. We should not enable these tests until we are sure, smoke tests are stable, so maybe this should only happen in May.
Failing macOS run for reference: !
Still not passing, deferring to a debt week
Change:
} const result: IInsetRenderOutput = { type: RenderOutputType.Extension, renderer, source: output, mimeType: pickedMimeTypeRenderer.mimeType }; <del> if (!this._webview?.insetMapping.has(result.source)) { </del> <ins> const inset = this._webview?.insetMapping.get(result.source); if (!inset || !inset.initialized) { </ins> const p = new Promise<void>(resolve => { this._register(Event.any(this.onDidRenderOutput, this.onDidRemoveOutput)(e => { if (e.model === result.source.model) {

Discussion:
Type: <bBug</ba jupyter notebook, create a python cell the cell the notebook two earch results the notebook bug One of the search results goes away <img width="1179" alt="Screenshot 2023-04-25 at 11 09 04 AM" src="https://user-"Making any changes to the search term makes both search results show again VS Code version: Code - Insiders 1.78.0-insider (Universal) (, 2023-04-25T05:41:22.331Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
new TextSearchMatch('preview 1', new OneLineRange(1, 1, 4)), new TextSearchMatch('preview 1', new OneLineRange(1, 4, 11))), aRawMatch('/2', new TextSearchMatch('preview 2', lineOneRange))]; <del> instantiationService.stub(ISearchService, searchServiceWithResults(results)); </del> <ins> instantiationService.stub(ISearchService, searchServiceWithResults(results, { limitHit: false, messages: [], results })); </ins> instantiationService.stub(INotebookSearchService, notebookSearchServiceWithInfo([], undefined)); const testObject: SearchModel = instantiationService.createInstance(SearchModel);

Discussion:
to , run a text search search is running, hit cancel on the "downloading repository index..." notification in the bottom right corner :bug: search view should show two messages (see below) but only the first one shows up !
Saw the notification about indexing but it was before I clicked search and now whenever I click search I don't see the notification come up.
I believe that you can try to do this with a larger repo (like ), and there should be enough time to cancel the index. Not too sure how to remove the index once it's downloaded, but you can try that first!
You can delete the downloaded index with the Delete All Repository Indexes command
The search result message changed but I see two messages at least !
Change:
"command.undoCommit": "Undo Last Commit", "command.checkout": "Checkout to...", "command.branch": "Create Branch...", <ins> "command.branchFrom": "Create Branch From...", </ins> "command.deleteBranch": "Delete Branch...", "command.renameBranch": "Rename Branch...", "command.merge": "Merge Branch...",

Discussion:
Similar to the visual-studio feature: Right now the way to do this would be to checkout the remote branch and then create a branch from there !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.678 --- <!-- score: 0.631 --- <!-- score: 0.585 --- <!-- score: 0.58 --- <!-- score: 0.53 --<!-- potentialduplicatescomment --
The command will show you a list of branches. If you pick a remote branch, it will create a local branch and set it to track the remote one. Isn't that enough?
this would require me to first checkout the remote branch
Please try <kbdF1</kbd, , pick a remote branch and let me know if that doesn't create a local branch.
it does create a local branch. I think I didn't explain the feature request correctly for example: When working on a new feature you create a branch from the remote master into your own local branch you have no need to actually create a local version of the branch. I never create a local branch tracking the remote branch
So, you want to create a branch based off a specific remote branch?
Exactly
I don't see a "Create Branch From" command, what happened to it?
The standard command now asks you where the branch should be created.
hey is there a way to set this branch to be the current branch by default?
What does that mean? When running the command, that branch will be checked out.
Sorry for not being very clear! Right now when I run this command I'm prompted to choose which branch to branch off every time. I quite liked it when the command would use the current branch as the branch to branch off of, without me having to specify it. I can see how the new behaviour is useful, but is there a way to set the old behaviour as the default behaviour, so that I don't have to confirm that I want to branch off the current branch when making a new branch?
The current experience auto selects ... so all you have to do is press <kbdEnter</kbdwhen asked which ref the branch should be created from. That is the equivalent of the old behaviour.
Change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { export interface TelemetryConfiguration { /** * Whether or not usage telemetry collection is allowed */ isUsageEnabled: boolean; /** * Whether or not crash error telemetry collection is allowed */ isErrorsEnabled: boolean; /** * Whether or not crash report collection is allowed */ isCrashEnabled: boolean; } export namespace env { /** * Indicates what telemetry is enabled / disabled * Can be observed to determine what telemetry the extension is allowed to send */ export const telemetryConfiguration: TelemetryConfiguration; /** * An {@link Event} which fires when the collectable state of telemetry changes * Returns a {@link TelemetryConfiguration} object */ export const onDidChangeTelemetryConfiguration: Event<TelemetryConfiguration | undefined>; } } </ins>

Discussion:
The current API does not expose the same level of internal granularity as the user setting allows. This proposal is to expose the telemetry levels. The current and can still be used a simpler API and this one can be considered more advanced and granular. Extension authors cannot just observe the user setting as this will lead to doing the wrong thing.
Another possibility is that we could collect an array of acceptable levels if we're worried about the possibility that the levels will not continue to be progressive but a permissions system instead. I.e. collecting errors and crashes would have be an array . None wouldn't really make sense in this context and would probably go away in favor of an empty array.
This is implemented but will remain in the proposed state for awhile for testing
Closing in favor of
Change:
} let quote: (s: string) => string; <del> let command = ''; </del> <ins> // begin command with a space to avoid polluting shell history let command = ' '; </ins> switch (shellType) {

Discussion:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Currently, when a debugger is executed (ie by hitting F5), a terminal is opened and the debugger is executed as a command. This command can get pretty long as it also changes to the working directory and sets some environment variables. Running the Python debugger in a simple project with only one file runs a command which is 243 characters long. This, however, means that these commands which are not meant to be run by the user but are instead run automatically are still included in the user's shell history file by default. I propose changing the command generation function to include a space at the very beginning - on many shells across various distros, is set to not add commands to history if they start with a space character. This also gives some control to the user whether they'd like for the debugger commands to be stored in history or not.
If you were wondering why someone might want this, I like that the history is there. All the time I go to my command line and use up arrow enter to rerun the last auto generated command. I've also gone through the history a bunch to rerun previous auto generated commands too.
Aye, this is why I opted for simply adding a space instead of something more aggressive such as - the shell is still in control whether to preserve history or not with . EDIT: Also, in my shell, commands which were run with a space can still be reached by pressing the up key in the active session, but I'm not sure this is the case in other shells.
This works for the integrated terminal, but I noticed the external terminal doesn't get the space on OSX !
On MacOS the leading space character seems to get dropped in the Applescript that talks to the Terminal application. So the feature at hand only works for the integrated terminal for now. I've created a for the external terminal. Since has verified that the fix works for the integrated terminal, I'm adding the "verified" label.
Change:
supports-color "^9.4.0" yargs "^17.7.2" <del> "@vscode/test-electron@^2.3.5": version "2.3.5" resolved "https://registry.yarnpkg.com/@vscode/test-electron/-/test-electron-2.3.5.tgz#c472c5bdce1329aeb4762b8aa7a2cbe7aa783aac" integrity sha512-lAW7nQ0HuPqJnGJrtCzEKZCICtRizeP6qNanyCrjmdCOAAWjX3ixiG8RVPwqsYPQBWLPgYuE12qQlwXsOR/2fQ== </del> <ins> "@vscode/test-electron@^2.3.8": version "2.3.8" resolved "https://registry.yarnpkg.com/@vscode/test-electron/-/test-electron-2.3.8.tgz#06a7c50b38cfac0ede833905e088d55c61cd12d3" integrity sha512-b4aZZsBKtMGdDljAsOPObnAi7+VWIaYl3ylCz1jTs+oV6BZ4TNHcVNC3xUn0azPeszBmwSBDQYfFESIaUQnrOg== </ins> dependencies: http-proxy-agent "^4.0.1" https-proxy-agent "^5.0.0"

Discussion:
See
I have not seen this before and I suspect an unhealthy CI, the log indicates a successful download to me: Code is here: I am using VS Code test module , so moving to
also indicates a broken stable download. Maybe this was just unlucky timing with us releasing a new version?
cc in case this is CDN related.
We need to bump to 2.3.8:
Change:
customPtyImplementation: (id, cols, rows) => new TerminalProcessExtHostProxy(id, cols, rows, this._terminalService), waitOnExit, name: this._createTerminalName(task), <del> initialText: task.command.presentation && task.command.presentation.echo ? formatMessageForTerminal(`Executing task: ${task._label}`, { excludeLeadingNewLine: true }) : undefined, </del> <ins> initialText: task.command.presentation && task.command.presentation.echo ? formatMessageForTerminal(nls.localize({ key: 'task.executing', comment: ['The task command line or label'] }, 'Executing task: {0}', task._label), { excludeLeadingNewLine: true }) : undefined, </ins> isFeatureTerminal: true, icon: task.configurationProperties.icon ? ThemeIcon.fromId(task.configurationProperties.icon) : undefined, color: task.configurationProperties.color

Discussion:
I noticed some task messages weren't localized: Terminal support for unicode is pretty great now so if we have issues with other languages here we should fix them.
Seems like a good idea. Changing these would only be an issue if we have extensions that are reading terminal output and looking for these strings.
That's a proposed api that will probably never get finalized, I doubt the few that use this would be checking for task messages like that.