jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> export class MoveToNextHunk extends AbstractInlineChatAction { constructor() { super({ id: 'inlineChat.moveToNextHunk', title: localize2('moveToNextHunk', 'Move to Next Change'), precondition: CTX_INLINE_CHAT_VISIBLE, f1: true, keybinding: { weight: KeybindingWeight.WorkbenchContrib, primary: KeyCode.F7 } }); } override runInlineChatCommand(accessor: ServicesAccessor, ctrl: InlineChatController, editor: ICodeEditor, ...args: any[]): void { ctrl.moveHunk(true); } } export class MoveToPreviousHunk extends AbstractInlineChatAction { constructor() { super({ id: 'inlineChat.moveToPreviousHunk', title: localize2('moveToPreviousHunk', 'Move to Previous Change'), f1: true, precondition: CTX_INLINE_CHAT_VISIBLE, keybinding: { weight: KeybindingWeight.WorkbenchContrib, primary: KeyMod.Shift | KeyCode.F7 } }); } override runInlineChatCommand(accessor: ServicesAccessor, ctrl: InlineChatController, editor: ICodeEditor, ...args: any[]): void { ctrl.moveHunk(false); } } </ins> export class CopyRecordings extends AbstractInlineChatAction { constructor() {

Discussion:
open inline chat have it make multiple hunks (hint: ask it to use a util that needs to be imported) there is no gesture to visit all hunks except for accepting/discarding them... This can also help with accessibility when using the move
To verify let inline chat make multiple changes, e.g ask it to import a util or let is change the label of two actions make sure the inline chat status says "N changes" (n=2) select and to navigate between the changes
Change:
private async getRepositoryExact(repoPath: string): Promise<Repository | undefined> { const repoPathCanonical = await fs.promises.realpath(repoPath, { encoding: 'utf8' }); <del> const openRepository = this.openRepositories.find(async r => { const rootPathCanonical = await fs.promises.realpath(r.repository.root, { encoding: 'utf8' }); return pathEquals(rootPathCanonical, repoPathCanonical); }); return openRepository?.repository; </del> <ins> for (const openRepository of this.openRepositories) { const rootPathCanonical = await fs.promises.realpath(openRepository.repository.root, { encoding: 'utf8' }); if (pathEquals(rootPathCanonical, repoPathCanonical)) { return openRepository.repository; } } return undefined; </ins> } private getOpenRepository(repository: Repository): OpenRepository | undefined;

Discussion:
Type: <bBug</bAfter todays update of the nightly, a workspace with multiple repos, is only showing the 1st one in the SCM tab VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-11T05:51:51.128Z) OS version: Darwin arm64 22.6.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ vscode-base640.1.0 inline-hasher1.1.0 spellright3.0.116 terraform2.27. vscode-kubernetes-tools1.3.13 indent-rainbow8.3.1 ytt-lint0.3.1 vscode-yaml1.13.0 vscode-gitweblinks2.9.2 kubernator-vscode1.0.0 code-spell-checker2.20.5 shellcheck0.32.6 sort-lines1.10.2 errorlens3.11.1 vscode-icons12.4.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
! !
could you please share the contents of to see if there are any regressions with the code that does the repository discovery when opening a multi-root workspace.
never mind. This is indeed a regression and I am pushing a fix now.
can someone trigger a build so I can test? The current nightly is in a state that is affecting my work.
sorry about that. Yes, we are spinning a new Insiders build that should be available later today.
Please download the latest Insiders released as it contains the fix for this issue.
I can confirm this is fixed on the latest build. thank you
thanks for reporting the issue!
Change:
} private onStacksChanged(e: IStacksModelChangeEvent): void { <ins> this.stacksChangedBuffer.push(e); this.onStacksChangeScheduler.schedule(); } private handleStacksChanged(): void { </ins> <del> // Up to date context </del> <ins> // Read and reset buffer of events const buffer = this.stacksChangedBuffer; this.stacksChangedBuffer = []; // Up to date context for all title controls </ins> POSITIONS.forEach(position => { <del> this.getTitleAreaControl(position).setContext(this.stacks.groupAt(position)); </del> <ins> const titleAreaControl = this.getTitleAreaControl(position); const context = this.stacks.groupAt(position); titleAreaControl.setContext(context); if (!context) { titleAreaControl.refresh(); // clear out the control if the context is no longer present } </ins> }); // Refresh / update if group is visible and has a position <del> const position = this.stacks.positionOfGroup(e.group); if (position >= 0) { if (e.structural) { this.getTitleAreaControl(position).refresh(); } else { this.getTitleAreaControl(position).update(); </del> <ins> buffer.forEach(e => { const position = this.stacks.positionOfGroup(e.group); if (position >= 0) { // group could be gone by now because we run from a scheduler with timeout if (e.structural) { this.getTitleAreaControl(position).refresh(); } else { this.getTitleAreaControl(position).update(); } </ins> } <del> } </del> <ins> }); </ins> } public get onGroupFocusChanged(): Event<void> {

Discussion:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via
Change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "3d4d6454007f14fa9a5f0e1fa49206fb91b676cc" </del> <ins> "commitHash": "4e4c7527c63fcf27dffaeb58bde996b8d859c0ed" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "4.2.9" </del> <ins> "version": "4.2.10" </ins> }, { "component": {

Discussion:
Issue Type: <bBug</bThe first Mac native tab has its top row cut off: ! The second one has the statusbar below the visible window: ! Resizing the window is a workaround. VS Code version: Code - Insiders 1.38.0-insider (, 2019-08-15T05:23:00.986Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (27)</summaryExtensionVersion ------ unique-lines1.0.0 ssh0.0.4 ghlink1.1.0 remotehub0.5.0 EditorConfig0.13.0 tslint1.0.44 git-project-manager1.7.1 rest-client0.22.0 solidity0.0.58 theme-karyfoundation-themes18.2.1 graphql-for-vscode1.15.1 vscode-docker0.7.0 remote-containers0.67.4 remote-ssh-edit-nightly2019.8. remote-ssh-explorer-nightly2019.8. remote-ssh-nightly2019.8. azure-account0.8.4 azurecli0.4.6 github-issues-prs0.9.1 debugger-for-chrome4.11.7 vetur0.22.1 vscode-versionlens0.24.0 vscode-yaml0.4.1 vscode-workspacecontains-canary0.0.2 vscode-open-in-github1.12.0 ayu0.18.0 vscodeintellicode1.1.9 </details<!-- generated by issue reporter --
does this reproduce when you disable grid layout?
Yes, it's the same with grid layout disabled.
I cannot reproduce using Electron 4.2.7
!
Fix is up at , should be available with next electron release.
we will take the new build and will push it via a PR.
Change:
windowId?: number; forceNewWindow?: boolean; <del> dialogOptions?: Electron.OpenDialogOptions; </del> <ins> dialogOptions?: OpenDialogOptions; </ins> telemetryEventName?: string; telemetryExtraData?: ITelemetryData;

Discussion:
There a few usages of in which is against our layering rules. I'd suggest to move the whole file into an folder
Unfortunately this might not be so simple given 62 references of which some would also need to be lifted up... An alternative would be to define similar interfaces that contain the properties we actually need instead of depending on Electron.
Also: and
I'd favour to lift them all instead blowing up our code size
with our current code organisation I cannot express the proper way for these references. Here are the issues: Moving this service into src/workbench This was my first idea, but it doesn't work. There are references from (our main side of things) into the windows service because the main side basically implements that service. We should not depend from to other than the file that we load into a window. The only way out I see here is to have something like for services that are shared between and . Moving the service from common into electron-browser This will not help because we have depending on the windows service and thus we would reach from into . The only option would be to introduce a new layer that contains the service and that can be accessed by and . To unblock your 2-CU scenario and to use ES6 features in workbench I suggest to that will inline the Electron references. However if we ever want to tackle this properly it needs some serious new code-structure layout on disk. Thoughts?
Yeah, makes sense... It's unfortunate but reality...
Change:
import { EditorPaneDescriptor, IEditorPaneRegistry } from 'vs/workbench/browser/editor'; import { Extensions as WorkbenchExtensions, IWorkbenchContributionsRegistry } from 'vs/workbench/common/contributions'; import { EditorExtensions, IEditorFactoryRegistry } from 'vs/workbench/common/editor'; <del> import { AcceptAllInput1, AcceptAllInput2, CompareInput1WithBaseCommand, CompareInput2WithBaseCommand, GoToNextConflict, GoToPreviousConflict, OpenBaseFile, OpenMergeEditor, OpenResultResource, SetColumnLayout, SetMixedLayout, ToggleActiveConflictInput1, ToggleActiveConflictInput2 } from 'vs/workbench/contrib/mergeEditor/browser/commands/commands'; </del> <ins> import { AcceptAllInput1, AcceptAllInput2, CompareInput1WithBaseCommand, CompareInput2WithBaseCommand, GoToNextUnhandledConflict, GoToPreviousUnhandledConflict, OpenBaseFile, OpenMergeEditor, OpenResultResource, SetColumnLayout, SetMixedLayout, ToggleActiveConflictInput1, ToggleActiveConflictInput2 } from 'vs/workbench/contrib/mergeEditor/browser/commands/commands'; </ins> import { MergeEditorInput } from 'vs/workbench/contrib/mergeEditor/browser/mergeEditorInput'; import { MergeEditor, MergeEditorResolverContribution, MergeEditorOpenHandlerContribution } from 'vs/workbench/contrib/mergeEditor/browser/view/mergeEditor'; import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle';

Discussion:
Testing Clone Use the command and select the folder Select in the quick pick It looks like the file has 4 conflict Pressing "Go to Next Conflict" highlights the first conflict Pressing "Go to Next Conflict" again does not do anything Also interesting that the editor minimap only has one conflict marker
I also saw this. It seemed to happen when both inputs make the same change.
On , once it moves past the first conflict and try to go back to it, it doesn't go back to it properly. !
This is weird, I cannot reproduce this. Also, for , I only have 2 conflicts. And this checkbox is also very weird: !
I'm on commit , not the latest commit. Does that make a difference?
If you can reproduce on the latest commit, can you try to give me a call?
yup, things look good on the latest on master for diff-merge-datasets for demo1. :) One thing I noticed, though, is that, if you're focused on the result and try to skip to next conflict, it's hard to tell by looking at the two inputs where the conflict is (seems that the two inputs aren't telling me anything in this screenshot): ! When I make the input editors a little bigger, then it starts making a little more sense. ! Not too big of a deal though, just wanted to bring your attention to it!
Change:
) { super(); if (!this.isEnabled()) { return; }

Discussion:
Testing When I open the Extensions Viewlet and choose from the overflow menu, I get a new/different list every time I execute the command. From a user's perspective, I don't understand why I keep getting a new list. I expect that when I issue the command VS Code shows me all of the recommended extensions. Otherwise, I keep clicking the menu to see what else might be recommended.
The ones that change are the tool based recommendations and the one we infer from telemetry. There is no ranking mechanism for these, and so are shuffled to give all a chance to be shown. What we can do is do the shuffle only once for each VS Code session. Sound ok?
yes, for each session sounds good. i can imagine that if we have not yet done the more costly recommendations then the 2nd or 3rd time i invoke that more are to the list.
I didnt follow that. Are you saying that we should keep adding to the list every time is invoked? Why?
Change:
} if (styles.listHoverBackground) { <del> content.push(`.monaco-list${suffix}:not(.drop-target) .monaco-list-row:hover:not(.selected):not(.focused) { background-color: ${styles.listHoverBackground}; }`); </del> <ins> content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { background-color: ${styles.listHoverBackground}; }`); </ins> } if (styles.listHoverForeground) { <del> content.push(`.monaco-list${suffix} .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); </del> <ins> content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); </ins> } if (styles.listSelectionOutline) {

Discussion:
See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug
Change:
return dom.getClientArea(this.container); } <del> layout() { </del> <ins> layout(widthInPixel?: number) { </ins> this._commentElements.forEach(element => { <del> element.layout(); </del> <ins> element.layout(widthInPixel); </ins> }); }

Discussion:
I have created a vscode extension which uses the comment thread and the comment thread width is too small after the update. This was working fine in version 1.79, here's a screenshot of the bug. <img width="1259" alt="Screenshot 2023-11-09 at 8 51 25 AM" src=""
Why are you still on 1.81 when the current release is 1.84.1?
sorry,I meant 1.84.1 I typed incorrectly.
I'm not able to reproduce this. Are there any more steps you took to arrive in this state?
create a comment thread in ur extension as shown below.
use the below code to create a comment thread in ur extension, edit the code to give dummy comments instead of reading it from a file. make sure the comment thread is Collapsed and in Edit mode.
This is the key. I can repo.
Change:
} async popStash(index?: number): Promise<void> { <del> try { const args = ['stash', 'pop']; </del> <ins> const args = ['stash', 'pop']; this.popOrApplyStash(args, index); } async applyStash(index?: number): Promise<void> { const args = ['stash', 'apply']; this.popOrApplyStash(args, index); } private async popOrApplyStash(args: string[], index?: number): Promise<void> { try { </ins> if (typeof index === 'number') { args.push(`stash@{${index}}`); }

Discussion:
I've attempted to find any other requests for this but didn't seem to see any. At the moment the CVS context menu shows: ! Only "Pop latest stash" and "Pop stash..." are visible. Is it possible to change the default stash behaviour to "apply" rather than "pop"? Additionally, is it possible to add two lines under "Pop stash..." for the same actions, just using apply: Apply latest stash Apply stash... I just lost a few hours and considerable amount of hair when a popped stash was deleted. I then had to sift through doing on each . Having "Apply stash..." easily accessible might be nicer.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.676 --<!-- potentialduplicatescomment --
I suggest to simply add and commands.
is anyone working on this, if not, I'll like to pick it up as a
looks like it might already be done in
yeah, just confirmed, Thanks. If I may ask, is there any rule around tagging an issue that is being worked on as it would be multiple efforts if I happen to have started it without anyone's knowledge. I've been scouting for an issue with no assignee to work on :-( Thanks for the catch tho!
Change:
const options = this._context.configuration.options; const layoutInfo = options.get(EditorOption.layoutInfo); <del> this._accessibilitySupport = options.get(EditorOption.accessibilitySupport); this._accessibilityPageSize = options.get(EditorOption.accessibilityPageSize); </del> <ins> this._setAccessibilityOptions(options); </ins> this._contentLeft = layoutInfo.contentLeft; this._contentWidth = layoutInfo.contentWidth; this._contentHeight = layoutInfo.height;

Discussion:
default shoudl be 100. As pointed out we should measure if this has a perf impact on Edge, Chromium and FF We can also increase the default value only if we see that a screen reader is detected
Change:
* @event */ export function onLanguage(languageId: string, callback: () => void): IDisposable { <del> const languageService = StandaloneServices.get(ILanguageService); const disposable = languageService.onDidRequestRichLanguageFeatures((encounteredLanguageId) => { if (encounteredLanguageId === languageId) { // stop listening disposable.dispose(); // invoke actual listener callback(); } </del> <ins> return StandaloneServices.withServices(() => { const languageService = StandaloneServices.get(ILanguageService); const disposable = languageService.onDidRequestRichLanguageFeatures((encounteredLanguageId) => { if (encounteredLanguageId === languageId) { // stop listening disposable.dispose(); // invoke actual listener callback(); } }); return disposable; </ins> }); <del> return disposable; </del> } /**

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Monaco Editor OS Version: macOS 13.0 (22A380) Steps to Reproduce: in the some logs in in vscode. any Monaco editor test page. the output of the consoleeach call to will re-register all registered languages. <img width="763" alt="image" src="https://user-"
Can you look into why this is the case, maybe even providing a PR?
Sorry for the late reply, I would be happy to submit a PR.
Change:
sideBySide = tree.useAltAsMultipleSelectionModifier ? (event.ctrlKey || event.metaKey) : event.altKey; } <del> this.openEditor(stat, { preserveFocus, sideBySide, pinned: isDoubleClick || (event && event.middleButton) }); </del> <ins> this.openEditor(stat, { preserveFocus, sideBySide, pinned: isDoubleClick }); </ins> } } return true; } <ins> public onMouseMiddleClick(tree: WorkbenchTree, element: ExplorerItem | Model, event: IMouseEvent): boolean { let sideBySide = false; if (event) { sideBySide = tree.useAltAsMultipleSelectionModifier ? (event.ctrlKey || event.metaKey) : event.altKey; } if (element instanceof ExplorerItem && !element.isDirectory) { this.openEditor(element, { preserveFocus: true, sideBySide, pinned: true }); } return true; } </ins> public onContextMenu(tree: WorkbenchTree, stat: ExplorerItem | Model, event: ContextMenuEvent): boolean { if (event.target && event.target.tagName && event.target.tagName.toLowerCase() === 'input') { return false;

Discussion:
VSCode Version: Version: 1.27.1 (user setup) Commit: Date: 2018-09-06T09:21:18.328Z Electron: 2.0.7 Chrome: 61.0.3163.100 8.9.3 V8: 6.1.534.41 Architecture: x64 OS Version: Windows 10 Pro 64-bit (10.0, Build ) Steps to Reproduce: click item in explorer icon appear ! If you open developers tools works as expected Does this issue occur when all extensions are disabled?: Yes/No Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.478 --- <!-- score: 0.463 --<!-- potentialduplicatescomment --
Hmm strangely I am no longer getting a event when I do a middle mouse click This nicely works in stable. I see we use a different electron 2.0.9 compared to 2.0.7 but not sure if that update includes something which would influence this. Also the middle click nicely works in the tabs title area - how are you handling it there? did we change something in the tree which might effect this?
yeah see I removed  to prepare for Electron 3.0.x. We should probably wire this into the tree so that people can react to it ("onMiddleClick"). Simply forwarding the was resulting in other issues.
ok so the tree should still listen on events but bobble them up in a different way ? I can create a PR for this and you review?
yeah, the thing is, middle-click should not trigger the click, otherwise we might get wrong behaviour where people do not expect middle-click to do anything. Instead we can check clients of the tree (and list?) that want to do something on middle click and update them accordingly. Otherwise every client has to do an extra check for which mouse button was used for click.
currently the only clients of the tree that check something on middle click are explorer and quick open . For the list they are open editors view and the breakpoints view, however this still works for the breakpoints view and does not work for the open editors due to