jiebi/CodeConvo huggingface dataset:
Code change:
const extension = await this.toScannedExtension(webExtension, true); if (extension.isValid || !scanOptions?.skipInvalidExtensions) { result.push(extension); <ins> } else { this.logService.info(`Skipping invalid additional builtin gallery extension ${webExtension.identifier.id}`); </ins> } } catch (error) { this.logService.info(`Ignoring additional builtin extension ${webExtension.identifier.id} because there is an error while converting it into scanned extension`, getErrorMessage(error));

Related discussion:
text: All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.
Code change:
const extension = await this.toScannedExtension(webExtension, true); if (extension.isValid || !scanOptions?.skipInvalidExtensions) { result.push(extension); <ins> } else { this.logService.info(`Skipping invalid additional builtin gallery extension ${webExtension.identifier.id}`); </ins> } } catch (error) { this.logService.info(`Ignoring additional builtin extension ${webExtension.identifier.id} because there is an error while converting it into scanned extension`, getErrorMessage(error));

Related discussion:
text: Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
Code change:
this._createCommentTheadWidget(info.owner, info.thread); const layoutInfo = (this.currentElement as CodeCellViewModel).layoutInfo; this.container.style.top = `${layoutInfo.outputContainerOffset + layoutInfo.outputTotalHeight}px`; <del> this.currentElement.commentHeight = dom.getClientArea(this._commentThreadWidget!.container).height; </del> <ins> this.currentElement.commentHeight = this._calculateCommentThreadHeight(this._commentThreadWidget!.getDimensions().height); </ins> return; } if (this._commentThreadWidget) { <del> if (info) { this._commentThreadWidget.updateCommentThread(info.thread); this.currentElement.commentHeight = dom.getClientArea(this._commentThreadWidget.container).height; } else { </del> <ins> if (!info) { </ins> this._commentThreadWidget.dispose(); this.currentElement.commentHeight = 0; <ins> return; } if (this._commentThreadWidget.commentThread === info.thread) { this.currentElement.commentHeight = this._calculateCommentThreadHeight(this._commentThreadWidget.getDimensions().height); return; </ins> } <ins> this._commentThreadWidget.updateCommentThread(info.thread); this.currentElement.commentHeight = this._calculateCommentThreadHeight(this._commentThreadWidget.getDimensions().height); </ins> } } })); } <ins> private _calculateCommentThreadHeight(bodyHeight: number) { const layoutInfo = this.notebookEditor.getLayoutInfo(); const headHeight = Math.ceil(layoutInfo.fontInfo.lineHeight * 1.2); const lineHeight = layoutInfo.fontInfo.lineHeight; const arrowHeight = Math.round(lineHeight / 3); const frameThickness = Math.round(lineHeight / 9) * 2; const computedHeight = headHeight + bodyHeight + arrowHeight + frameThickness + 8 /** margin bottom to avoid margin collapse */; return computedHeight; } </ins> private async _getCommentThreadForCell(element: ICellViewModel): Promise<{ thread: languages.CommentThread<ICellRange>; owner: string } | null> { if (this.notebookEditor.hasModel()) { const commentInfos = coalesce(await this.commentService.getNotebookComments(element.uri));

Related discussion:
text: have an eager comments controller extension (see below) open a notebook create a new cell leak warnings are printed
This seems to be rooted at  It looks like a new is created without always disposing the old one. The looks highly suspicious. <img width="1586" alt="Screenshot 2022-10-26 at 14 09 41" src="https://user-"
Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening
thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.
Thanks
Code change:
registerNotebookController(viewType: string, extensionData: NotebookExtensionDescription, controller: IMainNotebookController): IDisposable; registerNotebookSerializer(viewType: string, extensionData: NotebookExtensionDescription, serializer: INotebookSerializer): IDisposable; <del> withNotebookDataProvider(resource: URI): Promise<ComplexNotebookProviderInfo | SimpleNotebookProviderInfo>; </del> <ins> withNotebookDataProvider(resource: URI, viewType?: string): Promise<ComplexNotebookProviderInfo | SimpleNotebookProviderInfo>; </ins> getMimeTypeInfo(textModel: NotebookTextModel, output: IOutputDto): readonly IOrderedMimeType[];

Related discussion:
text: Verifying Version: 1.55.0-insider Commit: Date: 2021-03-25T16:24:13.227Z clone and open in vscode add a to F5 to run the extension Open an untitled file In the editor's tab, choose from the context menu, pick ! a different notebook is opened, no console log statement printed !
Are you able to open markdown notebooks without issue on non untitled files?
Yes, that works. I also tried to open a GitHub issue notebook on an untitled file and while a notebook seems to open which has a 'Github Issues' cell, the function in the GitHub issue notebook source seems not be called. So I'm a bit confused
I did some investigation with this and I can't reproduce it out of sources. When I select it through the reopen with dialog the notebook service receives the correct viewtype, although it always fails to open with the error . I'm not sure why it is failing as the inputs get created correctly and everything seems to be passing through the right way. Let me know if you want to investigate together.
Code change:
} private async getCustomBuiltinExtensionsFromGallery(scanOptions?: ScanOptions): Promise<IScannedExtension[]> { <del> const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (!extensions.length) { return []; } </del> if (!this.galleryService.isEnabled()) { this.logService.info('Ignoring fetching additional builtin extensions from gallery as it is disabled.'); return []; } const result: IScannedExtension[] = []; <ins> const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); </ins> try { const useCache = this.storageService.get('additionalBuiltinExtensions', StorageScope.APPLICATION, '[]') === JSON.stringify(extensions); const webExtensions = await (useCache ? this.getCustomBuiltinExtensionsFromCache() : this.updateCustomBuiltinExtensionsCache());

Related discussion:
text: All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.
Code change:
} private async getCustomBuiltinExtensionsFromGallery(scanOptions?: ScanOptions): Promise<IScannedExtension[]> { <del> const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (!extensions.length) { return []; } </del> if (!this.galleryService.isEnabled()) { this.logService.info('Ignoring fetching additional builtin extensions from gallery as it is disabled.'); return []; } const result: IScannedExtension[] = []; <ins> const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); </ins> try { const useCache = this.storageService.get('additionalBuiltinExtensions', StorageScope.APPLICATION, '[]') === JSON.stringify(extensions); const webExtensions = await (useCache ? this.getCustomBuiltinExtensionsFromCache() : this.updateCustomBuiltinExtensionsCache());

Related discussion:
text: Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
Code change:
this._overlayContainer.style.position = 'absolute'; this._overlayContainer.style.overflow = 'hidden'; <del> this.layoutContainerOverShadowElement(dimension, position); </del> <ins> this.layoutContainerOverShadowElement(dimension, /*position*/ undefined); </ins> if (this._webviewTransparentCover) { this._webviewTransparentCover.style.height = `${dimension.height}px`;

Related discussion:
text: I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps
Code change:
const RevealInSideBarForSearchResultsCommand: ICommandAction = { id: Constants.RevealInSideBarForSearchResults, <del> title: nls.localize('revealInSideBar', "Reveal in Explorer") </del> <ins> title: nls.localize('revealInSideBar', "Reveal in Side Bar") </ins> }; MenuRegistry.appendMenuItem(MenuId.SearchContext, {

Related discussion:
text: Issue Type: <bBug</bPerform a search In the results panel, right-click a filename Select 'Reveal in Explorer' File is highlighted in the 'Files' side panel. VS Code version: Code 1.39.2 (, 2019-10-15T15:35:18.241Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ Bookmarks10.5.0 cucumberautocomplete2.14.1 vscode-svgviewer2.0.0 vscode-markdownlint0.31.1 vscode-eslint1.9.1 vscode-scss-formatter1.4.2 perforce3.2.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
what you refer to as "the 'Files' side panel" is called Explorer. So the current behaviour of 'Reveal in Explorer' from a filename in Search results makes sense. But I can see it's confusing because when you then right-click on the filename that's been revealed in VS Code's Explorer, you get another 'Reveal in Explorer', and that one opens a Windows Explorer onto the folder containing the file and highlights the file. I guess on macOS the equivalent context menu will say 'Reveal in Finder'.
Exactly.
So maybe the option in the Search side bar's context menu should be recaptioned 'Reveal in Explorer Side Bar' (1 change): Alternatively, make the Explorer side bar context menu on Windows use the caption 'Reveal in Windows Explorer' (3 changes):
fyi
I'm still on Windows, I right-click the tab of an open file, and it offers and .
on my 1.39.2 on Windows the context menu from a file tab captions the options "Reveal in Explorer" and "Reveal in Side Bar" (not "Open in ..." as you wrote). So for consistency I think the context menu from the filename on the Search list should be changed on this line to become
Fair enough. My point, though, was obviously regarding the inconsistency in numerology across the application.
We talked about this at the time. The thing is, "Explorer" is used in a bunch of places to refer to the file explorer in vscode and it doesn't seem like a big deal to me.
Code change:
const RevealInSideBarForSearchResultsCommand: ICommandAction = { id: Constants.RevealInSideBarForSearchResults, <del> title: nls.localize('revealInSideBar', "Reveal in Explorer") </del> <ins> title: nls.localize('revealInSideBar', "Reveal in Side Bar") </ins> }; MenuRegistry.appendMenuItem(MenuId.SearchContext, {

Related discussion:
text: However I realized that there is precedent for referring to it as "Side bar", the command "File: Reveal active file in side bar". I think that's kind of imprecise and also you are already looking at the search results in the side bar, so it doesn't make sense to "reveal in side bar" again. But anyway, I don't have a strong opinion.
We have been using the term "side bar" exactly for this reason: to have a way to distinguish between the Windows Explorer and the explorer in VSCode. We could in theory refer to it as "Explorer View", but that may cause frustration when users search for "reveal explorer" and find 2 results. I think no matter what we do, both commands should have a similar label. I don't think there is an issue calling the command in the search results "Reveal in Side Bar".
That'd be nice and clear.
are you willing to take my PR for this? It failed CI on windows and darwin but as far as I can tell that wasn't caused by anything in my PR itself.
Code change:
import * as nls from 'vs/nls'; import * as DOM from 'vs/base/browser/dom'; <ins> import { lastIndex } from 'vs/base/common/arrays'; </ins> import { IStorageService } from 'vs/platform/storage/common/storage'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { IThemeService, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; import { EditorPaneSelectionChangeReason, EditorPaneSelectionCompareResult, IEditorOpenContext, IEditorPaneSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection } from 'vs/workbench/common/editor'; <del> import { getDefaultNotebookCreationOptions, NotebookEditorWidget } from 'vs/workbench/contrib/notebook/browser/notebookEditorWidget'; </del> <ins> import { getDefaultNotebookCreationOptions } from 'vs/workbench/contrib/notebook/browser/notebookEditorWidget'; </ins> import { IEditorGroup } from 'vs/workbench/services/editor/common/editorGroupsService'; import { NotebookDiffEditorInput } from '../../common/notebookDiffEditorInput'; import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation';

Related discussion:
text: Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.
Code change:
import * as nls from 'vs/nls'; import * as DOM from 'vs/base/browser/dom'; <ins> import { lastIndex } from 'vs/base/common/arrays'; </ins> import { IStorageService } from 'vs/platform/storage/common/storage'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { IThemeService, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; import { EditorPaneSelectionChangeReason, EditorPaneSelectionCompareResult, IEditorOpenContext, IEditorPaneSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection } from 'vs/workbench/common/editor'; <del> import { getDefaultNotebookCreationOptions, NotebookEditorWidget } from 'vs/workbench/contrib/notebook/browser/notebookEditorWidget'; </del> <ins> import { getDefaultNotebookCreationOptions } from 'vs/workbench/contrib/notebook/browser/notebookEditorWidget'; </ins> import { IEditorGroup } from 'vs/workbench/services/editor/common/editorGroupsService'; import { NotebookDiffEditorInput } from '../../common/notebookDiffEditorInput'; import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation';

Related discussion:
text: Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" alt="image" src="https://user-"
Code change:
} else { // automagically convert some argument types <ins> let hasBuffers = false; </ins> const toArgs = cloneAndChange(args, function (value) { if (value instanceof extHostTypes.Position) { return extHostTypeConverter.Position.from(value);

Related discussion:
text: Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this
Code change:
const text = outputInfo.text(); const outputScrolling = scrollingEnabled(outputInfo, ctx.settings); <del> const content = createOutputContent(outputInfo.id, [text], ctx.settings.lineLimit, ctx.settings.outputScrolling, false); </del> <ins> const content = createOutputContent(outputInfo.id, [text], ctx.settings.lineLimit, outputScrolling, false); </ins> content.classList.add('output-plaintext'); if (ctx.settings.outputWordWrap) { content.classList.add('word-wrap');

Related discussion:
text: [ ] Notebooks (.ipynb files) [X] Interactive Window and/or Cell Scripts (.py files with #%% markers) When rendering large output, I now get the option to at the bottom of the output in addition to the previous "text editor" view. However, when selecting this option, the full output is not rendered in the scrollable element. Instead, the ellipsis shown in the truncated view remain. The expected outcome would be that the content shown in the scrollable element would be the full output, not the truncated output. When changing the setting , the scrollable element is displayed immediately and shows the content as expected. To reproduce: Initial output: ! Output after clicking : ! Output when setting : ! 78.2 v2023.4. Python v3.8.13 No response No response Local