jiebi/CodeConvo huggingface dataset:
Change:
} protected _createReportExtensionIssueAction(element: IRuntimeExtension): Action | null { <ins> if (element.marketplaceInfo) { return this._instantiationService.createInstance(ReportExtensionIssueAction, element.description); } </ins> return null; }

Discussion:
I'm an extension author and frequently have issues open with generic titles ("Extension issue") and not enough information to do anything with (usually ending " We have written the needed data into your clipboard. Please paste! " or a similar message about attaching a file) (). I see VS Code gets many issues the same, and has a bot to close them. It seems unfortunate that users are taking time to come to GitHub and submit issues, but they often end up closed due to not having enough information. It's not clear to me what prompts users to create these issues, but perhaps there are ways that they could be improved. For example: populating the title with "Extension issue" makes it easy for a user to submit without entering a single word of text about the problem. If the field was left blank, they would not be able to submit the form without typing something that might give some indication of what prompted them to file the issue. perhaps GitHub could detect this string (or some variation of) and give the user a nudge that maybe they have forgotten to paste/attach something? (I know that's a request for GitHub, but they don't have a public issue tracker and perhaps this team has contacts there ) include some summary of the data in the clipboard in the originally message (I've no idea what it is, because I don't know if anybody has ever successfully pasted it).. querystrings can be fairly long these days even if the whole message can't be included
may also help reduce these.
Ah yes, that might help too. Out of interest, do you know what is prompting users to create these, and what sort of information is included in the clipboard? I'm not sure I've ever had anyone come back to me with the data (likely because their clipboard has been reused by the time they see my response) so I've zero ideas about what might be happening.
these are created by the Issue Reporter: ! ! The PR linked upped the max number of characters so we should see a lot less of those issues. That said, it is suspicious that they all have the title "Extension Issue"... makes me wonder if someone wrote a script of some kind to spam issues.
Hmm, that is odd - in your screenshot both the title and body are mandatory, but I get "Extension issue" so often from different peope, I'd be surprised if they were all typing it: !

coming from here maybe?
Nice find. Looks like that gets run from this page: ! Looks like a relic of the past... let me see what I can do here
Ok I have a PR out that will route that through the issue reporter instead.
neat, thanks!
this code does similar: is a recent example of an issue created that way but lacking the clipboard-pasted info.
Verification steps: Open Running Extensions Right click on an extension and click report issue The Issue reporter should open and not
Change:
configFileWatcher.onDidDelete(handleProjectCreateOrDelete, this, this._disposables); configFileWatcher.onDidChange(handleProjectChange, this, this._disposables); <del> const allModeIds = this.getAllModeIds(descriptions); </del> <ins> const allModeIds = this.getAllModeIds(descriptions, pluginManager); </ins> this.client = this._register(new TypeScriptServiceClient( workspaceState, version => this.versionStatus.onDidChangeTypeScriptVersion(version),

Discussion:
tsserver could provide a list of languages so that when a document other than and is opened, the plugins would be notified. Angular language service relies on this to parse files in Angular templates. There seems to be a regression whereby languages provided by tsserver plugins are no longer synced (does not have buffer sync support). This was brought to light by in For potential fix, please see cc:
Related We only prototyped the support for external languages in TypeScript so this is not really an official API. You'd have to check with the TS team to see if this is still something they are interested in properly supporting as there is other work required beyond this
I merged a pr that fixes this so you can test it and provide feedback, but you must not ship anything to customers that relies on this API. It is not official and may be changed or be removed at any point in the future
Thanks for the update. I'll test it out locally. I'd like to organize a meeting to finalize the design with the Typescript team, so that we can move on with the implementation.
Change:
if (!this.visible) { return; } <ins> this.ui.container.classList.remove('hidden-input'); </ins> const visibilities: Visibilities = { title: !!this.title || !!this.step || !!this.buttons.length, description: !!this.description || !!this.step, inputBox: true, message: true }; this.ui.setVisibilities(visibilities); super.update(); if (this.ui.inputBox.value !== this.value) {

Discussion:
When creating a new profile, the input has no margins: ! Compare that with the rename one: !
I am using the quick pick in the same way for both and I do not know how they are rendered differently. So moving to for his insights.
Ah so the difference seems to be that the first one isn't the first quickpick that is shown... first we see: ! Then we see the first input box you've shared. So I'm thinking theres some CSS class bleeding through
Change:
if (!textContent) { return; } <ins> const focusedElement = getActiveWindow().document.activeElement; </ins> const range = new globalThis.Range(); range.setStart(textContent, selectionOffsetStart); range.setEnd(textContent, selectionOffsetEnd); activeDocumentSelection.removeAllRanges(); activeDocumentSelection.addRange(range); <ins> if (isHTMLElement(focusedElement)) { focusedElement.focus(); } </ins> } }

Discussion:
Enable the setting Open the editor Open the find widget Type several letters The editor is focused as soon as there is a match for the find result It is no longer possible to continue typing in the find widget without retriggering the focusing of the find widget
Change:
} private hideSelectDropDown() { <del> if (!this.contextViewProvider) { </del> <ins> if (!this.contextViewProvider || !this._isVisible) { </ins> return; } <ins> this._isVisible = false; </ins> this.contextViewProvider.hideContextView(); }

Discussion:
VSCode Version: Code - Insiders 1.20.0-insider (, 2017-12-19T07:32:34.862Z) OS Version: Windows_NT x64 10.0. Extensions: none Steps to Reproduce: Debug panel the top SelectBox [SelectBox expands] again at the same spot Expected result: SelectBox closes. Actual result: It stays expanded. It affects SelectBox on Debug and Output panels. Terminal panel SelectBox closes as expected.
thanks for the nice bug report, forwarding to fyi
Thanks, good bug find!
Fixed With:
thanks. the verified label should not be until our endgame where we verify all the bugs we had during a milestone. I will remove it so that we can have someone else verify the bug.
Thanks
Change:
async run(accessor: ServicesAccessor) { const terminalService = accessor.get(ITerminalService); if (terminalService.isProcessSupportRegistered) { <del> const instance = terminalService.createTerminal(); </del> <ins> const instance = terminalService.createTerminal({ target: terminalService.configHelper.config.defaultLocation }); </ins> if (!instance) { return; }

Discussion:
The terminal commands and are used for both the panel buttons and the commands in the CP (that we do want to use the defaultLocation for). Not sure how to differentiate between them - don't think we want to duplicate the actions. let me know what you think
Let's wait until after is done since that will likely add target support to the create commands
Other reproes: Ctrl / Cmd J to open the panel - terminal editor is created focus the terminal editor, click the trash can on the panel , close the editor tab - a bunch of errors in the console
Change:
private createExplorerViewDescriptor(): IViewDescriptor { return { id: ExplorerView.ID, <del> name: this.contextService.getWorkspace2().name, </del> <ins> name: this.getExplorerCaption(), </ins> location: ViewLocation.Explorer, ctor: ExplorerView, order: 1

Discussion:
Today we show the workspace name it seems.
! What does "title" mean? 1 or 2?
2
It should be FOLDERS in multi root mode, and foldername_ otherwise, right?
Right
It behaves exactly in this way currently. I suppose this issue should be closed.
We should first ask if he can still repro this issue since is not seeing it, are tehre special repro steps
There are no special steps to repro this, so please confirm
!
I still cannot reproduce this. Also, your layout differs from mine - control buttons on the EXPLORER bar. Could you please explain, how I can switch VSCode into such a view?
I have "open editors" section disabled.
Change:
constructor() { super({ <del> id: NotebookIndentUsingSpaces.ID, </del> <ins> id: NotebookIndentationToTabsAction.ID, </ins> title: nls.localize('convertIndentationToTabs', "Convert Indentation to Tabs"), precondition: undefined, });

Discussion:
to repro: click notebook indentations statusbar entry run "indent using spaces/tabs" and select a new number entry will not update, however indentations work correctly given the selection that the user made and the current settings.

No a "choose intentation type" entry in status bar when editing in a notebook. I have a notebook with tab indentation but it seems theres some global spaces setting that overrides it... even pasting a literal tab charachter inserts spaces :/ !
False alarm. The status bar entry just moved so much that I didn't see it right away, and it has a different name in the status bar entries context menu.
Actually, looks like the status bar is really slow to update. I saw it update eventually, but I'm not sure what caused it to finally show the correct thing. !
Change:
this.updatedAllowedExtension(providerId, accountName, extensionId, extensionName, true); this.removeAccessRequest(providerId, extensionId); <del> this.storageService.store(`${extensionName}-${providerId}`, session.id, StorageScope.GLOBAL, StorageTarget.MACHINE); </del> <ins> this.storageService.store(`${extensionName}-${providerId}-${scopes.join('-')}`, session.id, StorageScope.GLOBAL, StorageTarget.MACHINE); </ins> quickPick.dispose(); resolve(session);

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: OS Version: Steps to Reproduce: an extension that does this: 'll notice that is though it should exist because we created it on line 1. This is because we cache the session id based on the provider id & extension name but really we should be caching them based on provider id, extension name, AND SCOPES. This will allow the 3rd time to find the session created in the first line.
Verification steps: The code session3 should not be undefined.
is your solution to this issue the reason that the Insiders builds have started bugging me at least once a day to sign into GitHub? With four windows open, each with two extensions that want a GitHub token (GitLens and GitHub Issues and Pull Requests), I have to generate 8 tokens to make VS Code stop bugging me... at which point it almost always discovers a VS Code update, and often we do the dance again after it restarts.
(And never mind, I see it was, and I see you fixed it!)
Reopening this because I reverted the change that fixed it.
just checking to see if there were any updates on this issue?
haven't had a chance to revisit this. You can take a look at my commit if you'd like. The problem I needed to address is migrating from the old storage keys to the new storage keys and my commit didn't handle that. Unfortunately, I have some other work I'm working on at the moment so I won't be able to look at this this month.
This appears to be fixed. Closing now
verification: original steps to repro. Instead, session3 should be defined.
Change:
async reverseContinue(args: DebugProtocol.ReverseContinueArguments): Promise<DebugProtocol.ReverseContinueResponse | undefined> { if (this.capabilities.supportsStepBack) { <ins> this.stoppedSinceLastStep = false; </ins> const response = await this.send('reverseContinue', args); <del> this.fireSimulatedContinuedEvent(args.threadId); </del> <ins> if (!this.stoppedSinceLastStep) { this.fireSimulatedContinuedEvent(args.threadId); } </ins> return response; } return Promise.reject(new Error('reverseContinue not supported'));

Discussion:
Stepping using the debug adapter that I helped develop has been broken by a VS Code change between 1.78.2 and 1.79.0. I used a to log the messages sent back and forth using the same extension version, but different VS Code versions. I attached the logs below. After diffing the two files, the only difference is that the "scopes" request isn't sent to the adapter after the "next" request reports a stopped event. The end result is that the debugging UI in VS Code is stuck in "running" mode even though the debug adapter is stopped, and the user has no way to advance. See
I think this is related to the fact that you send the "stopped" event before the "next" response. We should be able to support that but as a workaround you could respond to "next" before stopping the debugger.
Thanks for the quick response I will look into that workaround. In what cases is tit required? Any type of step?
I see the issue but it will be too much of a risky change to get into our next stable release. I will try to address it in July but I'd recommend working around it in your extension.
I understand. I implemented the workaround in my extension and initial tests show that it works, so thanks for making me aware of that.
For my own reference, I think it should be ok to do immediately instead of waiting for the response.
Hi what are some verification steps for this issue?
<!-- 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!
I verified this by hacking mock-debug, but are you able to verify the change in Insiders, or have you moved on to not rely on that behavior anymore?
I've modified my extension to implement your workaround. I can download an old version of the extension to test this if you want.
It's ok, I think I've got it now
Change:
value = value.replace(/@installed/g, '').replace(/@sort:(w+)(-w*)?/g, '').trim().toLowerCase(); <del> const matchingText = (e: IExtension) => (e.name.toLowerCase().indexOf(value) > -1 || e.displayName.toLowerCase().indexOf(value) > -1) </del> <ins> const matchingText = (e: IExtension) => (e.name.toLowerCase().indexOf(value) > -1 || e.displayName.toLowerCase().indexOf(value) > -1 || e.description.toLowerCase().indexOf(value) > -1) </ins> && (!categories.length || categories.some(category => (e.local && e.local.manifest.categories || []).some(c => c.toLowerCase() === category))); let result;

Discussion:
Type: <bBug</bextensions view, search Bug No results ! ! I'd expect to see autopep8 listed as the word appears in its description is shown in the normal extension results without using VS Code version: Code - Insiders 1.84.0-insider (Universal) (, 2023-10-24T05:35:10.309Z) OS version: Darwin arm64 23.0.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
this.templateData.container.classList.toggle('cell-editor-focus', this.viewCell.focusMode === CellFocusMode.Editor); } <del> private applyDecorations() { // apply decorations this._register(this.viewCell.onCellDecorationsChanged((e) => { e.added.forEach(options => { if (options.className) { this.notebookEditor.deltaCellContainerClassNames(this.viewCell.id, [options.className], []); this.templateData.rootContainer.classList.add(options.className); } }); e.removed.forEach(options => { if (options.className) { this.notebookEditor.deltaCellContainerClassNames(this.viewCell.id, [], [options.className]); this.templateData.rootContainer.classList.remove(options.className); } }); })); this.viewCell.getCellDecorations().forEach(options => { if (options.className) { this.notebookEditor.deltaCellContainerClassNames(this.viewCell.id, [options.className], []); this.templateData.rootContainer.classList.add(options.className); } }); } </del> override dispose() { this._isDisposed = true;

Discussion:
Testing I select a set of cells with Shift+Click, and I hit Ctrl+F to open the find widget. The cells are then highlighted as such: <img width="981" alt="image" src=""I scroll down a full page length, and then scroll back up. The cells are now highlighted as such, with no click or type input on my part: <img width="980" alt="image" src=""It appears that the Code cells lost their yellow highlight.
Change:
readonly onDidInitiateOpenFilesTrustRequest: Event<void>; readonly onDidInitiateWorkspaceTrustRequest: Event<WorkspaceTrustRequestOptions | undefined>; <ins> readonly onDidInitiateWorkspaceTrustRequestOnStartup: Event<void>; </ins> completeOpenFilesTrustRequest(result: WorkspaceTrustUriResponse, saveResponse?: boolean): Promise<void>; requestOpenFilesTrust(openFiles: URI[]): Promise<WorkspaceTrustUriResponse>;

Discussion:
I created a brand new VM and attached remote-ssh to it, then opened my folder on it. I clicked to trust the folder, then immediately after I was prompted by the terminal to trust the folder again. Every time I open a new folder thereafter I'm again double prompted for trust.
this is how we use the API, is promise for the original prompt not being shared with successive requests or something?
All callers of should be sharing the same promise. I will try to set up a repro today and see if I can reproduce the problem locally.
Here is what is happening: initial workspace trust modal dialog is being displayed there is another workspace trust dialog displayed due to the call the workspace will actually resolve the promise and in the background you can see the terminal is initiated The workspace trust request dialog is not being dismissed. I do have couple of ideas that I will discuss with
The fix will be available in Friday's Insiders release.
Change:
key: item.legacyAnnouncementSettingsKey!, migrateFn: (announcement, accessor) => { const configurationKeyValuePairs: ConfigurationKeyValuePairs = []; <del> const sound = accessor(item.legacySoundSettingsKey); </del> <ins> const sound = accessor(item.settingsKey)?.sound || accessor(item.legacySoundSettingsKey); </ins> if (announcement !== undefined && typeof announcement !== 'string') { announcement = announcement ? 'auto' : 'off'; } configurationKeyValuePairs.push([`${item.settingsKey}`, { value: announcement !== undefined ? { announcement, sound } : { sound } }]); <ins> configurationKeyValuePairs.push([`${item.legacyAnnouncementSettingsKey}`, { value: undefined }]); configurationKeyValuePairs.push([`${item.legacySoundSettingsKey}`, { value: undefined }]); </ins> return configurationKeyValuePairs; } })));

Discussion:
have the -setting open settings editor and notice a warning It seems that we are missing a settings migration. That's something we usually do when "breaking" a setting. <img width="715" alt="Screenshot 2024-02-22 at 11 30 06" src=""
This was by design this iteration to be overly cautious with the migration with plans to do that next iteration Now that it's been tested via a TPI, I think it's safe to do this. cc who also requested this during testing.
Verifier: Pls add a bunch of alert and audio cue settings such as: in various orders and combinations. Verify that they're transformed into settings and the deprecated settings are all removed.
It looks like I have to reload the window for the User settings to be migrated. Is that behaviour expected?
Yes because that will happen automatically for users when they download the vs code update
Change:
private onInputKeyUp(keyboardEvent: IKeyboardEvent) { switch (keyboardEvent.keyCode) { case KeyCode.Enter: <ins> this.onSearchSubmit(); </ins> this.searchOnTypeDelayer.trigger(() => this._onSubmit.fire(false), 0); return; case KeyCode.Escape:

Discussion:
With current implementation of search history it's a bit hard to find previous "proper" searches when is . When used with regular expressions which are not as fast to type as regular text it allows to quickly see RE errors or preliminary results but also saves each a lot of version with only 1-3 changed characters to history. Without better options to navigate field history except <kbdUp</kbd/<kbdDown</kbdit makes hard to find history entry for intentional searches (in my case it was about 20 intermediate results to spot proper search). Current solutions are: 1) Disable and then only "submitted" searches will be in history. 2) Increase to 2s and hope that I can type all capturing groups and lookaheads fast enough, but it might be faster just to hit <kbdEnter</kbdAs for me - ideal solution will be an option to treat searches triggered by as early preview of possible matches and add history entry only after user intentionally hits <kbdEnter</kbd. Is it something that can be implemented and considered by the team? /cc
I think it would make sense to add to history either on enter, or on a "large" (2 seconds maybe) debounce.
Looks like same problem appears in "files to include/exclude" fields (even more spam entries) so I created PR that will debounce saving history entries for these fields too. And the another related question: Will you consider merging PR that will add Setting to completely disable history entries on type and will require explicit <kbdEnter</kbdpress (off by default) or it's unnecessary complexity (which might be source of confusion) that wont be merged? It will basically turn "search on type" into some kind of Search preview mode - ideal for me, but would understand if it's not good for general auditory.
Thanks for the PR, I've merged it. As for the setting, if you propose a good name and description text I think it's reasonable.
Change:
return this._proxy.setTerminalLayoutInfo(args); } async getTerminalLayoutInfo(args: IGetTerminalLayoutInfoArgs): Promise<ITerminalsLayoutInfo | undefined> { <del> return await this._proxy.getTerminalLayoutInfo(args); </del> <ins> // This is optional as we want reconnect requests to go through only if the pty host exists. // Revive is handled specially as reviveTerminalProcesses is guaranteed to be called before // the request for layout info. return this._optionalProxy?.getTerminalLayoutInfo(args); </ins> } async requestDetachInstance(workspaceId: string, instanceId: number): Promise<IProcessDetails | undefined> {

Discussion:
some terminals and type in them the window or restart VS Code they don't persist Started happening in OSS on Wednesday July 5th
is undefined !
it gets set to !
that's the return value (see )
yes, true. but the call returns so it's getting reset somewhere. not via !
I'm on to the cause... The process is getting killed after detaching on reload, so reconnect breaks: Revive after restart is working for me.
Ah found it: Investigating...
Parsed state is null so reconnect stops here: