jiebi/CodeConvo huggingface dataset:
Code change:
} if (shadowElement) { <del> this.updateShadowElement(shadowElement, dimension, position); </del> <ins> this.updateShadowElement(shadowElement, dimension, /*position*/ undefined); </ins> } if (this._shadowElementViewInfo && this._shadowElementViewInfo.width <= 0 && this._shadowElementViewInfo.height <= 0) {

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 userExtensions = await this.webExtensionsScannerService.scanUserExtensions(profileLocation ?? this.userDataProfileService.currentProfile.extensionsResource); extensions.push(...userExtensions); } <del> return Promise.all(extensions.map(e => toLocalExtension(e))); </del> <ins> return extensions.map(e => toLocalExtension(e)); </ins> } async install(location: URI, options: InstallOptions = {}): Promise<ILocalExtension> {

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 userExtensions = await this.webExtensionsScannerService.scanUserExtensions(profileLocation ?? this.userDataProfileService.currentProfile.extensionsResource); extensions.push(...userExtensions); } <del> return Promise.all(extensions.map(e => toLocalExtension(e))); </del> <ins> return extensions.map(e => toLocalExtension(e)); </ins> } async install(location: URI, options: InstallOptions = {}): Promise<ILocalExtension> {

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:
} getScopedEnvironmentVariableCollection(scope: vscode.EnvironmentVariableScope | undefined): IEnvironmentVariableCollection { <del> if (this._extension && scope) { // TODO: This should be removed when the env var extension API(s) are stabilized checkProposedApiEnabled(this._extension, 'envCollectionWorkspace'); } </del> const scopedCollectionKey = this.getScopeKey(scope); let scopedCollection = this.scopedCollections.get(scopedCollectionKey); if (!scopedCollection) {

Related discussion:
text: For example: Context:
As we anticipate we might need shell scoping as well in the future, use something similar to instead. Updated proposal: One issue with this is that carries optional properties. Hence an alternative could be:
The required would need to be removed when we a second one anyway, we can just treat and the same as
Sorry what do you mean by the "second one"? Mostly I was trying to follow : But I guess we don't have to strictly follow it?
by a second one I mean a second scope, we don't want the user to explicitly enumerate all the scopes to set it which would do.
Updated proposal:
Closing in favor of as these issues were only open to finalize proposed API.
Moving this out of June as it's a feature request.
I was expecting this so it's easier to understand for an API user:
That's what I had initially had , you're the one who recommended that perhaps we should put it inside itself:
API sync also seemed to be in agreement with that, but maybe we should check again.
my mistake, I forgot some of the conversations as this has gone through a few iterations
Based on discussion in API sync, we should probably deprecate existing API and merge it with the scoped one (similar to )
Assigning myself too so it's easier for me to track
When viewing contributions, is it possible to open the preview of the markdown directly instead of the file? ! as opposed to ! I can open preview using: !
since this is an advanced feature I think the raw markdown is more flexible as the user can navigate and copy section of it better. So I don't think this is a necessary change personally
Feedback before finalization: Add an interface implements Add to the Clarify how scoped interacts with the non-scoped collection Don't deprecate
Should we also call out how it's applied in addition to (and after) the global collection? Looks good otherwise
Sure, I have modified the docstrings to append it I plan to have the implementation ready but only merge and adopt it in Python extension next week to avoid multiple iterations.
Code change:
}); } <ins> private onDidChangeActivityBarLocation(): void { this.updateTitleArea(); const id = this.getActiveComposite()?.getId(); if (id) { this.onTitleAreaUpdate(id!); } this.updateActivityBarVisiblity(); this.rememberActivityBarVisiblePosition(); } </ins> override updateStyles(): void { super.updateStyles();

Related discussion:
text: Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!
Code change:
// folder.1=>folder.2 if (isFolder && name.match(/(d+)$/)) { <del> return name.replace(/(d+)$/, (match: string, ...groups: any[]) => { return strings.pad(parseInt(groups[0]) + 1, groups[0].length); }); </del> <ins> return name.replace(/(d+)$/, (match: string, ...groups: any[]) => { let number = parseInt(groups[0]); return number < maxNumber ? strings.pad(number + 1, groups[0].length) : strings.format('{0}.1', groups[0]); }); </ins> } // 1.folder=>2.folder if (isFolder && name.match(/^(d+)/)) { <del> return name.replace(/^(d+)/, (match: string, ...groups: any[]) => { return strings.pad(parseInt(groups[0]) + 1, groups[0].length); }); </del> <ins> return name.replace(/^(d+)(.*)$/, (match: string, ...groups: any[]) => { let number = parseInt(groups[0]); return number < maxNumber ? strings.pad(number + 1, groups[0].length) + groups[1] : strings.format('{0}{1}.1', groups[0], groups[1]); }); </ins> } // file/folder=>file.1/folder.1

Related discussion:
text: Have file named in explorer Copy/paste it Window hangs This is from We shouldn't attempt this when the number is = Number.MAXSAFEINTEGER. It loops forever here: This bug will happen whenever incrementFileName fails to modify the file name.
I guess only interesting thing about this what we should do in this case as we need to create some new file name? Add without changing the original number?
that sounds reasonable
Code change:
// Each line and column clause have 6 groups (ie no. of expressions in round brackets) export const lineAndColumnClauseGroupCount = 6; <del> const MAX_LENGTH = 2000; </del> <ins> const InvalidLinkResult = 'Invalid Link Result'; const MAX_LENGTH = 2000; let map = new Map<string, TerminalLink | string>(); </ins> export class TerminalValidatedLocalLinkProvider extends TerminalBaseLinkProvider { constructor( private readonly _xterm: Terminal,

Related discussion:
text: Logging errors from the file service I notice that the terminal seems to stat the terminal prompt multiple times: ! Notice the at the end of the file path.
When you hover a line in the terminal links are resolved, one of the link providers gets confirmation on whether it's a file or directory and gives a high confidence link (underline shows when you hover without cmd) and on macOS we treat as a valid path character. This is how it's always worked. but we could cache this stat result with a TTL (10s?) so it doesn't spam so many stat calls and will be able to return the link faster on successive hovers.
Code change:
}) ); } <del> export const foldBackgroundBackground = registerColor('editor.foldBackground', { light: transparent(editorSelectionBackground, 0.3), dark: transparent(editorSelectionBackground, 0.3), hcDark: null, hcLight: null }, nls.localize('foldBackgroundBackground', "Background color behind folded ranges. The color must not be opaque so as not to hide underlying decorations."), true); export const editorFoldForeground = registerColor('editorGutter.foldingControlForeground', { dark: iconForeground, light: iconForeground, hcDark: iconForeground, hcLight: iconForeground }, nls.localize('editorGutter.foldingControlForeground', 'Color of the folding control in the editor gutter.')); </del>

Related discussion:
text: <!-- 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. --When folded, folding ranges are displayed in the editor as a single line with darkened background. Hovever (as of ), on the minimap, the background of this line is not darkened. This makes it harder to navigate using the minimap. !
Either this isn't working or steps are non trivial
Ok, see this working unless I have render characters enabled
Code change:
import { TerminalStatus } from 'vs/workbench/contrib/terminal/browser/terminalStatusList'; import Severity from 'vs/base/common/severity'; import { ICommandService } from 'vs/platform/commands/common/commands'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </ins> export class EnvironmentVariableInfoStale implements IEnvironmentVariableInfo { readonly requiresAction = true;

Related discussion:
text: Testing Show extension display name instead of extension id. You can also make them links to open the extension editor. <img width="522" alt="image" src="https://user-"
what's the right way to do this? I had a look and could only see async methods to do this which seemed odd to me (and would require some refactoring to get the tooltip to work with async).
1 I see this as well
There are multiple ways depending upon the source of this extension id. Since it is a running extension, I would prefer to use this api since you do not want to have async
thanks will use that. You don't have an id -name map to avoid iterating over it multiple times though?
There exists one, but it is async
Code change:
} } <ins> export class LineSequence implements ISequence { constructor( private readonly trimmedHash: number[], private readonly lines: string[] ) { } getElement(offset: number): number { return this.trimmedHash[offset]; } get length(): number { return this.trimmedHash.length; } getBoundaryScore(length: number): number { const indentationBefore = length === 0 ? 0 : getIndentation(this.lines[length - 1]); const indentationAfter = length === this.lines.length ? 0 : getIndentation(this.lines[length]); return 1000 - (indentationBefore + indentationAfter); } } function getIndentation(str: string): number { let i = 0; while (i < str.length && (str.charCodeAt(i) === CharCode.Space || str.charCodeAt(i) === CharCode.Tab)) { i++; } return i; } </ins> class Slice implements ISequence { private readonly elements: Int32Array; private readonly firstCharOnLineOffsets: Int32Array;

Related discussion:
text: Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:
Code change:
declare function require(path: string): any; <del> const enabledSetting = 'markdown.math.enabled'; </del> <ins> const markdownMathSetting = 'markdown.math'; </ins> export function activate(context: vscode.ExtensionContext) { function isEnabled(): boolean {

Related discussion:
text: It would be nice to have a entry in the configuration section of markdown-math extension. A place where users could put their custom math macros.
<!-- 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!
/verified
Code change:
displayName: Extract openssl prebuilt # inspired by: https://github.com/emk/rust-musl-builder/blob/main/Dockerfile <del> - bash: | set -e sudo apt-get update sudo apt-get install -yq build-essential curl file git graphviz musl-dev musl-tools linux-libc-dev pkgconf zip unzip xutils-dev ninja-build sudo ln -s "/usr/bin/g++" "/usr/bin/musl-g++" || echo "link exists" displayName: Install build dependencies </del> <ins> - ${{ if or(eq(parameters.VSCODE_BUILD_LINUX_ALPINE_ARM64, true), eq(parameters.VSCODE_BUILD_LINUX_ALPINE, true)) }}: - bash: | set -e sudo apt-get update sudo apt-get install -yq build-essential musl-dev musl-tools linux-libc-dev pkgconf xutils-dev sudo ln -s "/usr/bin/g++" "/usr/bin/musl-g++" || echo "link exists" displayName: Install musl build dependencies </ins> - ${{ if eq(parameters.VSCODE_BUILD_LINUX_ARMHF, true) }}: - bash: | set -e sudo apt-get install -yq gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf binutils-arm-linux-gnueabihf <del> displayName: Install cross compilation toolchains </del> <ins> displayName: Install arm32 toolchains - ${{ if eq(parameters.VSCODE_BUILD_LINUX_ARM64, true) }}: - bash: | set -e sudo apt-get install -yq gcc-aarch64-linux-gnu g++-aarch64-linux-gnu binutils-aarch64-linux-gnu displayName: Install arm64 toolchains </ins> - task: NodeTool@0 inputs:

Related discussion:
text: The stage is now a bottleneck to having the platform specific stages run: ! Each job compiles each target serially. We could further parallelize all targets across different jobs. !
Code change:
// do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

Related discussion:
text: a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.
Code change:
// do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

Related discussion:
text: I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by