jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> public getCommentsAtLine(commentRange: Range | undefined): ReviewZoneWidget[] { return this._commentWidgets.filter(widget => widget.getGlyphPosition() === (commentRange ? commentRange.endLineNumber : 0)); } </ins> public async addOrToggleCommentAtLine(commentRange: Range | undefined, e: IEditorMouseEvent | undefined): Promise<void> { // If an add is already in progress, queue the next add and process it after the current one finishes to // prevent empty comment threads from being added to the same line. if (!this._addInProgress) { this._addInProgress = true; // The widget's position is undefined until the widget has been displayed, so rely on the glyph position instead <del> const existingCommentsAtLine = this._commentWidgets.filter(widget => widget.getGlyphPosition() === (commentRange ? commentRange.endLineNumber : 0)); </del> <ins> const existingCommentsAtLine = this.getCommentsAtLine(commentRange); </ins> if (existingCommentsAtLine.length) { const allExpanded = existingCommentsAtLine.every(widget => widget.expanded); existingCommentsAtLine.forEach(allExpanded ? widget => widget.collapse() : widget => widget.expand(true));

Discussion:
Type: <bFeature Request</bCC any file containing comment thread editor, move your cursor to any line having comment your cursor is on the line, press ctrl+K ctrl+I to see if the comment tolltip opens Screen reader users cannot open comment tooltip on the current line via ctrl+K ctrl+I ctrl+K ctrl+I needs to work for the comment tooltip just like other tooltips. VS Code version: Code - Insiders 1.93.0-insider (, 2024-08-20T08:04:15.567Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
the comment widget is not a tooltip. We cannot reuse this keybinding to focus the comment widget because it's possible that line will have hover info. pls lmk if you disagree. I do wonder if we should have a focus closest comment widget command/keybinding.
Aw, I see. Please then consider adding a keybinding to focus the closest comment widget. Currently, alt+F9 and shift+alt+F9 go to the next and previous comment widget, but there is no action available to focus the comment on the current line.
It does make sense to have an "Expand and focus comment at current line" command.
The new command is "Focus Comment on Current Line" with no default keybinding.
To verify: Install an extension that provides comments GitHub Pull Requests can be used for this Sign in Open the Pull Requests view Open a file diff for a PR. If there aren't any comments in the file, add a comment on one of the changed lines and collapse the comment Put your cursor on a line in a file with a collapsed comment Open the command palette and run the command "Focus Comment on Current Line" Verify that the comment has focus
This should probably be to the comments and/or the editor accessibility help dialog for discoverability.
Change:
} } <del> async storeEditSession(): Promise<string | undefined> { </del> <ins> async storeEditSession(fromStoreCommand: boolean): Promise<string | undefined> { </ins> const folders: Folder[] = []; <ins> let hasEdits = false; </ins> for (const repository of this.scmService.repositories) { // Look through all resource groups and compute which files were added/modified/deleted

Discussion:
Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.
Change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import { Emitter } from 'vs/base/common/event'; export class DebugCompoundRoot { private stopped = false; private stopEmitter = new Emitter<void>(); onDidSessionStop = this.stopEmitter.event; sessionStopped(): void { if (!this.stopped) { // avoid sending extranous terminate events this.stopped = true; this.stopEmitter.fire(); } } } </ins>

Discussion:
Ever since I started using the new JS debugger, when running our top level target and then manually closing the code-oss window, the and targets remain: ! Eventually, maybe 1 minute later, the goes away, but the other one stays, I always have to manually disconnect from it. ! cc
This is because is set for the shared process and extension host, which allows them to reconnect when vscode is reloaded. Eventually js-debug in extension host gives up, but the shared process is using the previous Node debugger which doesn't give up. Both these are working as designed, this is kind of a downside of the compound launch configs in that there's no "compound stop".
Yeah, would actually LOVE a compound stop. Could this be a feature of compounds, & Meaning, if something like was set in the compound, all targets would share the same action, and I would see no actions.
We could add a attribute to the compound, however how would that work? Clicking stop on any of the compound sessions would send stop to all sessions? And it would never be rendered as dicsonnect?
Maybe compound launch configs could have a pseudo-root, which has a "stop" action that affects all individual configs? ` The compound config could have an option whether sessions can be stopped individually, or whether stopping one session is treated as stopping the whole set of configuration.
ok makes somewhat sense, the flaw of my proposel is that once compound starts 4 sessions those sessions are not related in any way. So adding a pseudo root might be smart. The pseudo root would not be rendered, and the pseudo root would remember the attribute. Here are code pointers for a PR. We should add the attribute and to the schema . Code pointer for the debug session to add the pseudo root stopAll smartness
I like both options.
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Please let's have the bot not do this for ourselves.
BTW, the bot's wording sounds wrong: in to the latest...
Much better, and I this attribute to our compound config. But the behavior partly confuses me and I opened
Change:
ShowMostRecentOutputAction, TestingSortByLocationAction, TestingSortByStatusAction, <ins> TestingSortByDurationAction, </ins> TestingViewAsListAction, TestingViewAsTreeAction, ToggleInlineTestOutput,

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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:
Change:
let tcp: string = ''; let tcp6: string = ''; try { <del> tcp = fs.readFileSync('/proc/net/tcp', 'utf8'); tcp6 = fs.readFileSync('/proc/net/tcp6', 'utf8'); </del> <ins> tcp = await pfs.readFile('/proc/net/tcp', 'utf8'); tcp6 = await pfs.readFile('/proc/net/tcp6', 'utf8'); </ins> } catch (e) { // File reading error. No additional handling needed. }

Discussion:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app
Change:
async function copyVscodeDevLink(gitAPI: GitAPI, useSelection: boolean) { try { <del> const permalink = getPermalink(gitAPI, useSelection, getVscodeDevHost()); </del> <ins> const permalink = getLink(gitAPI, useSelection, getVscodeDevHost()); </ins> if (permalink) { return vscode.env.clipboard.writeText(permalink); }

Discussion:
a desktop clone open with some uncommitted changes Continue Edit Session open on :bug: edit session is not applied The reason for this is that we are opening a permalink instead of preserving the current branch checkout so the edit session identifier doesn't match up and the edit session doesn't get applied. This used to work and regressed with the edit session identifier API work, which applies stricter checks to edit session identities. Thanks for finding this in !
not seeing a command
sorry, that should have been , not
Change:
}; }; } <del> runWhenGlobalIdle = (runner) => _runWhenIdle(globalThis, runner); </del> <ins> runWhenGlobalIdle = (runner, timeout) => _runWhenIdle(globalThis, runner, timeout); </ins> })(); export abstract class AbstractIdleValue<T> {

Discussion:
See It appears to timeout
I cannot explain this, we hang here: Which would suggest that we were unable to complete creating all workbench contributions. But I do not find anything in the logs that would hint into a direction
Change:
} } <ins> const isBigSur = isMacintosh && release() > '20.0.0'; </ins> // If we are started with --wait create a random temporary file // and pass it over to the starting instance. We can use this file // to wait for it to be deleted to monitor that the edited file

Discussion:
Testing macOS Mojave 10.14.6 Version: 1.61.0-insider (Universal) Commit: Date: 2021-09-28T05:14:06.244Z Electron: 13.4.0 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 18.7.0 open terminal run
Same with
Nice catch! Two things to be done: 1) Rewire the cli to use old code path for macOS <= 10.15 for the endgame 2) Write wrapper around to be used instead of as follow-up.
Can someone explain what is different in Big Sur compared to older versions?
from the error above the following 3 std pipe arguments are not available on older distros. tool is not public, so I couldn't find the exact release notes where this behavior was changed. For now, the safer change is to not use the path pre Big Sur while we explore alternatives using for these versions in upcoming milestone.
Ok thanks, do we have an issue for that?
Tracked in
Change:
// Normalize the link and remove any leading ./ or ../ since quick access doesn't understand // that format link = normalize(link).replace(/^(.+/)+/, ''); <ins> // If any of the names of the folders in the workspace matches // a prefix of the link, remove that prefix and continue this._workspaceContextService.getWorkspace().folders.forEach((folder) => { if (link.substr(0, folder.name.length + 1) === folder.name + (isWindows ? '' : '/')) { link = link.substring(folder.name.length + 1); return; } }); </ins> const results = await this._searchService.fileSearch( this._fileQueryBuilder.file(this._workspaceContextService.getWorkspace().folders, { filePattern: link,

Discussion:
Issue Type: <bBug</b! by ctrl+leftclick to open a file in Terminal, a path like xx/xxx/xx/xx.c could be open and xx.c:13:3 could be open because recently opened, and auto jump to line/col but a path with line/col number like xx/xxx/xx/xx.c:13:3 can't be open VS Code version: Code 1.56.2 (, 2021-05-12T17:13:13.157Z) OS version: WindowsNT x64 10.0. Remote OS version: Linux x64 5.4.72-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ remote-ssh0.65.4 remote-ssh-edit0.65.6 remote-wsl0.56.4 vim1.20.3 githistory0.6.16 cpptools1.4.0 hexeditor1.6.0 </details<!-- generated by issue reporter --
Links of that form work, your issue is because you have the folder opened and files are only resolved relative to the root folder. So it would work fine if you opened the parent folder of . I guess we could special case this to remove the first path segment if it matches the opened folder (ie. the initial cwd of the terminal).
Code pointer:
Thanks for your reply, Its very helpful for me to understand that, I add parent folder of codec to workspace, and it works as expect, much appreciated.
I suppose I can work on this. From what I understand, all I have to do is check if the prefix of the search query matches the root folder directory. If it does, we erase that first part and resume the code as usual, right?
pretty much yep, make sure it's a folder (link contains /, or  on windows) and a test would be good too which should be fairly easy to write in the existing test file.
I checked the code pointer that you sent above, but it doesn't seem like it points to the right place (this is my first time navigating the VS Code repository so there's a good chance that I'm wrong). I did some research and ended up in "", specifically .

I one line (just to make sure I'm in the right place) that logs a message to the console whenever the user enters a new character in Quick Open, and it worked. Isn't that where I should be working? How is the terminal related to this issue?
we wouldn't want to change the quick access code but what the terminal sends to it:
Change:
return { suggestions: agents.map((agent, i): CompletionItem => { <del> const { label: agentLabel, isDupe } = getAgentCompletionDetails(agent, agents, this.chatAgentNameService); </del> <ins> const { label: agentLabel, isDupe } = this.getAgentCompletionDetails(agent); </ins> return { // Leading space is important because detail has no space at the start by design label: isDupe ?

Discussion:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.
Change:
const items: MarkerTableItem[] = []; for (const resourceMarker of this.resourceMarkers) { for (const marker of resourceMarker.markers) { <del> if (marker.resource.scheme === network.Schemas.walkThrough || marker.resource.scheme === network.Schemas.walkThroughSnippet || marker.resource.scheme === network.Schemas.vscodeSourceControl) { </del> <ins> if (unsupportedSchemas.has(marker.resource.scheme)) { </ins> continue; }

Discussion:
Testing <img width="1617" alt="image" src="https://user-"
I can't get squiggles to show up for the commit input box at all, even after following the steps from the linked TPI. What are some steps to verify this, or maybe someone else can verify?
Thanks Reopening the bug as the fix for this has introduced a regression.
Checked in a better fix for this issue. Should be included in tomorrow's Insiders release (2022-08-26).
closedWith
Verified, but the actions in the hover don't do anything: !
Thanks I have filed to track the issue with the actions.
Change:
"tab.inactiveBackground": "#34352f", "tab.border": "#1e1f1c", "tab.inactiveForeground": "#ccccc7", // needs to be bright so it's readable when another editor group is focused <del> "tab.lastPinnedBorder": "#75715E", </del> <ins> "tab.lastPinnedBorder": "#414339", </ins> "widget.shadow": "#000000", "progressBar.background": "#75715E", "badge.background": "#75715E",

Discussion:
The grey used as the pinned tab separator could be a bit stronger and I suggest it is the same grey as for the View separators. !
Yeah, this color is pretty much randomly selected. would you be interested in picking colors for our default themes? Just today I pushed to add the color to our default themes but I did not really spend a lot of time thinking about which color fits best. Most often I picked the border color of the peek view inside the editor. The color key is
Are we sure we don't want to push this as a default for all themes? Because out of the box it's nearly impossible to tell the difference in other themes. Like below, can you tell which files are pinned? !
yeah if you can find a good base color and rule for it, I am all up for it
Change:
outline: none !important; } <del> .monaco-workbench .notebookOverlay.notebook-editor-editable > .cell-list-container > .monaco-list > .monaco-scrollable-element > .scrollbar.visible { </del> <ins> .monaco-workbench .notebookOverlay.notebook-editor > .cell-list-container > .monaco-list > .monaco-scrollable-element > .scrollbar.visible { </ins> z-index: var(--z-index-notebook-scrollbar); cursor: default; }

Discussion:
VS Code version: 1.66.0 Jupyter Extension version (available under the Extensions sidebar): v2022.3. Python Extension version (available under the Extensions sidebar): v2022.4.0 OS (Windows Linux distro) and version: Windows 10 21H2 Python and/or Anaconda version: Python 3.9.7, Miniconda 4.12.0 Type of virtual environment used (N/A ...): python & conda environment both have this problem. Jupyter server running: Local & Remote both have this problem. Click and drag the vertical scroll bar should be able to scroll the window vertically. When hover the mouse over the scroll bar, it does not respond to click and drag. Touchpad works though. jupyter interactive window. the following code: click and drag the vertical scroll bar on the right. It does not work.
Thanks for the issue. This would be a vscode core issue. Seems like something is capturing the mouse input.
I would transfer it to VS code, but github seems to be having a problem with transferring at the moment.
I can no longer click on the scrollbar for the interactive window? Would this be your area?
I see this, only in the interactive window and not a normal notebook, seems like something must be covering the scrollbar but I can't figure out what
Same as issue
Hey I was wondering if there is a solution to this? I am being confronted with the same issue.
Change:
import { IExtension, ExtensionState, IExtensionsWorkbenchService, VIEWLET_ID, IExtensionsViewPaneContainer, IExtensionContainer, TOGGLE_IGNORE_EXTENSION_ACTION_ID, SELECT_INSTALL_VSIX_EXTENSION_COMMAND_ID, THEME_ACTIONS_GROUP, INSTALL_ACTIONS_GROUP } from 'vs/workbench/contrib/extensions/common/extensions'; import { ExtensionsConfigurationInitialContent } from 'vs/workbench/contrib/extensions/common/extensionsFileTemplate'; import { IGalleryExtension, IExtensionGalleryService, ILocalExtension, InstallOptions, InstallOperation, TargetPlatformToString, ExtensionManagementErrorCode } from 'vs/platform/extensionManagement/common/extensionManagement'; <del> import { IWorkbenchExtensionEnablementService, EnablementState, IExtensionManagementServerService, IExtensionManagementServer, IWorkbenchExtensionManagementService } from 'vs/workbench/services/extensionManagement/common/extensionManagement'; </del> <ins> import { IWorkbenchExtensionEnablementService, EnablementState, IExtensionManagementServerService, IExtensionManagementServer } from 'vs/workbench/services/extensionManagement/common/extensionManagement'; </ins> import { ExtensionRecommendationReason, IExtensionIgnoredRecommendationsService, IExtensionRecommendationsService } from 'vs/workbench/services/extensionRecommendations/common/extensionRecommendations'; import { areSameExtensions, getExtensionId } from 'vs/platform/extensionManagement/common/extensionManagementUtil'; import { ExtensionType, ExtensionIdentifier, IExtensionDescription, IExtensionManifest, isLanguagePackExtension, getWorkspaceSupportTypeMessage, TargetPlatform } from 'vs/platform/extensions/common/extensions';

Discussion:
Look at telemetry and if not a lot of users are using the Install and Do not Sync extension action remove the action to simplify the Extension Install flow. is the action name. fyi
Ok was run on 59K distinct machines. For comparison extensionGallery:install was executed on 10.4M machines. So Do not Sync is used in 0.5% of cases. I think it is fine if we remove it - we keep it somewhere but not so prominent. what do you think?
Any suggestions?
We already have the "Sync Extension" check in the Extension context menu when it is installed - this is great. ! And we already have the "Sync Extension" check in the same context menu when it is not installed. Just currently if I click this, there is no effect. So ideally the experience would be that I can uncheck this before installing the extension. And thus we need no new actions. !
Lets try this in insiders already and see if we get any hit back.
Awesome - thanks!
Change:
depth?: number; } <ins> export interface InitOptions { defaultBranch?: string; } </ins> export interface BranchQuery { readonly remote?: boolean; readonly pattern?: string;

Discussion:
I would have expected that the command creates a repository with a branch 'main'. I was using the latest insider: This is the repository created using 'Publish to Github'
Related to
In this particular scenario we should honor the default branch setting on GitHub rather than the VS Code setting.
Change:
export class ShowPreviousChangeAction extends EditorAction { <del> constructor() { </del> <ins> constructor(private readonly outerEditor?: ICodeEditor) { </ins> super({ id: 'editor.action.dirtydiff.previous', label: nls.localize('show previous change', "Show Previous Change"),

Discussion:
Found while working on a file tracked by git and make two distinct changes in separate lines the same file on the other side the dirty diff gutter marker on each of the editors to open the dirty diff views the outer editor on the right-hand side the action on the left-hand side dirty diff editor The right-hand side dirty diff editor jumps to the next change !
Change:
*/ linesDecorationsClassName?: string | null; /** <ins> * If set, the decoration will be rendered in the lines decorations with this CSS class name, but only for the first line in case of line wrapping. */ firstLineDecorationClassName?: string | null; /** </ins> * If set, the decoration will be rendered in the margin (covering its full width) with this CSS class name. */ marginClassName?: string | null;

Discussion:
When a section is wrapped after folding. Fold its parent with itself unfolded will display several wrong fold indicators.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.724 --- <!-- score: 0.616 --- <!-- score: 0.606 --- <!-- score: 0.575 --- <!-- score: 0.569 --<!-- potentialduplicatescomment --
!