jiebi/CodeConvo huggingface dataset:
Code change:
private _updateTabActionBar(profiles: ITerminalProfile[]): void { const actions = getTerminalActionBarArgs(TerminalLocation.Panel, profiles, this._getDefaultProfileName(), this._terminalProfileService.contributedProfiles, this._terminalService, this._dropdownMenu); <ins> this._registerDisposableActions(actions.dropdownAction, actions.dropdownMenuActions); </ins> this._newDropdown?.update(actions.dropdownAction, actions.dropdownMenuActions); }

Related discussion:
text: I was trying to understand the usage of and the lifecycle of actions created while creating it. I think this originated with the terminal, so looked at the terminal code, but it seems like the problem isn't solved here either. instantiates some Actions which extend Disposable, but they are never tracked or disposed. The ActionViewItems returned from are apparently owned by whatever calls that and get disposed, but not these extra actions that we have to create. So, one solution would be for them to be owned and disposed by although that feels unexpected. But otherwise, there isn't a technically correct way for the code in to know when they should be disposed. Wondering whether I'm missing something or if you have any thoughts.
I spent some time investigating this and the issue is that we use in some places and in others. Only the latter is disposable. This would be a bit involved to rework
Code change:
const newCellListHeight = Math.max(newBodyHeight - topInserToolbarHeight, 0); if (this._list.getRenderHeight() < newCellListHeight) { // the new dimension is larger than the list viewport, update its additional height first, otherwise the list view will move down a bit (as the `scrollBottom` will move down) <del> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight, overrideStyles: this._listStyleOverride }); </del> <ins> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight }); </ins> this._list.layout(newCellListHeight, dimension.width); } else { // the new dimension is smaller than the list viewport, if we update the additional height, the `scrollBottom` will move up, which moves the whole list view upwards a bit. So we run a layout first. this._list.layout(newCellListHeight, dimension.width); <del> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight, overrideStyles: this._listStyleOverride }); </del> <ins> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight }); </ins> } this._overlayContainer.style.visibility = 'visible';

Related discussion:
text: I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Code change:
if (action instanceof MenuItemAction) { const location = { viewColumn: ACTIVE_GROUP }; const actions = getTerminalActionBarArgs(location, this._terminalProfileService.availableProfiles, this._getDefaultProfileName(), this._terminalProfileService.contributedProfiles, this._terminalService, this._dropdownMenu); <ins> this._registerDisposableActions(actions.dropdownAction, actions.dropdownMenuActions); </ins> const button = this._instantiationService.createInstance(DropdownWithPrimaryActionViewItem, action, actions.dropdownAction, actions.dropdownMenuActions, actions.className, this._contextMenuService, { hoverDelegate: options.hoverDelegate }); return button; }

Related discussion:
text: I was trying to understand the usage of and the lifecycle of actions created while creating it. I think this originated with the terminal, so looked at the terminal code, but it seems like the problem isn't solved here either. instantiates some Actions which extend Disposable, but they are never tracked or disposed. The ActionViewItems returned from are apparently owned by whatever calls that and get disposed, but not these extra actions that we have to create. So, one solution would be for them to be owned and disposed by although that feels unexpected. But otherwise, there isn't a technically correct way for the code in to know when they should be disposed. Wondering whether I'm missing something or if you have any thoughts.
I spent some time investigating this and the issue is that we use in some places and in others. Only the latter is disposable. This would be a bit involved to rework
Code change:
} public show(top: number, newContent: string | undefined, metadata: NotebookCellMetadata | undefined): void { <del> this.element.style.visibility = 'visible'; </del> <ins> this.element.style.visibility = ''; </ins> this.element.style.top = `${top}px`; if (typeof newContent === 'string' || metadata) { this.updateContentAndRender(newContent ?? this._content.value, metadata ?? this._content.metadata);

Related discussion:
text: Collapse an output, it is not hidden in the webview <img width="596" alt="image" src="https://user-"
maybe ?
Code change:
"dependencies": { "@vscode/extension-telemetry": "0.5.1", "request-light": "^0.5.8", <del> "vscode-languageclient": "^8.0.1", </del> <ins> "vscode-languageclient": "^8.0.2-next.4", </ins> "vscode-nls": "^5.0.1" }, "devDependencies": {

Related discussion:
text: Version: 1.68.0-insider Commit: Date: 2022-06-02T05:17:01.962Z open the Settings JSON editor add some unnecessary commas no problems reported in the problems view. open the JSON Language Server log. Observe that there are no diagnostic requests. Other requests are sent and completed, so the language server is running.
Maybe unrelated: I was expecting "trailing comma" warnings in (we recently changed the schema to not accept them), but they only started showing after I flushed the schema cache (using the UI command) and reloaded the window (I can't completely rule out that a window reload alone would have helped).
I checked that with the fix the trailing commas are reported
Code change:
result.edits.push(<languages.IWorkspaceFileEdit>{ oldResource: entry.from, newResource: entry.to, <del> options: entry.options, </del> <ins> options: { ...entry.options, contentsBase64: entry.options?.contents && encodeBase64(VSBuffer.wrap(entry.options.contents)) }, </ins> metadata: entry.metadata });

Related discussion:
text: Add support for setting the contents of files created by workspace edits My proposed would be to add a option to : For , we want to support copying images from desktop into with drag and drop. Right now we have to use the apis to create the image file Using a workspace edit would let us express the entire operation in a single , which will play more nicely with undo/redo
Looks like support for this may already exist internally: However getting a of new file data from the extension host to the main process may be tricky. We can only efficiently serialize a if it is a top level argument to an RPC call or if the entire object is wrapped in a (which has a perf cost). Open to ideas on how to handle this
I do like the and believe the cost is manageable - we don't send edits is large frequencies and of large sizes. I can take a look at this but it honestly is stretch for June - there is some debt in how workspace edits are represented on the wire and I would take this issue as a reason to clean things up
work started here: I didn't bother with or hoisting the data to the top but instead it uses quick and dirty base64 encoding. I'd suggest we go with that and see how it works out over time.
Code change:
showMethods: true, showFunctions: true, showConstructors: true, <ins> showDeprecated: true, </ins> showFields: true, showVariables: true, showClasses: true,

Related discussion:
text: I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense
Code change:
}); test('fuzzyScore2 (matching)', function () { <del> const target = 'HeLlo-World'; </del> <ins> const target = 'HelLo-World'; </ins> for (const offset of [0, 3]) { <del> let [score, matches] = _doScore2(offset === 0 ? target : `123${target}`, 'HeLlo-World', offset); </del> <ins> let [score, matches] = _doScore2(offset === 0 ? target : `123${target}`, 'HelLo-World', offset); </ins> assert.ok(score); assert.strictEqual(matches.length, 1);

Related discussion:
text: I'm not certain if this is a bug (in the tests), but while looking at the completion ranking I noticed there are some tests cases for the fuzzy scoring annotated with "direct case match" that don't appear to match exactly - the order of the lowercase/capital is reversed: It's possible this is deliberate (because VS Code handles some swapped characters), but if so I would've thought an exact match would be included also (to ensure it ranks above the entry with the reverse characters) and the comment would be more explicit. There are other tests in the same file with the same mismatch.
Code change:
setCompositeBarItems(items: ICompositeBarItem[]): void { this.model.setItems(items); <del> this.updateCompositeSwitcher(); </del> <ins> this.updateCompositeSwitcher(true); </ins> } getPinnedComposites(): ICompositeBarItem[] {

Related discussion:
text: have insiders with settings sync enabled add exploration build to the sync select replace local when prompted so that exploration because just like insiders over time insiders UI state gets ruined, e.g the side bar is populated with views I have carefully hidden and rearranged
This is caused due to the dependency between two states and . Values of both states changed together from outside Change event for first state is triggered. Updating to this change can cause view container changes like (registering or deregistering) This triggers internal change events to update pinned viewlets Updating pinned viewlets is updating the stored value for second state Bug is caused at the last step -pinned viewlets state is getting overriden without refreshing its in-memory state.
How would this be verified?
<!-- 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!
Since it cannot be reproduced easily, I would ask to verify this.
the steps are as easy as described in or the description of this issue. use settings sync onboard another machine :bug: view state of the main machine get's broken: views reappear, views are reordered etcpp
Can you please verify this? I believe this depends on some pre-existing state therefore not everyone can reproduce. This state is not trivial to set up. Since you have this state already, it might be easier for you to verify.
Code change:
//#endregion //#region Task <del> /** * Controls how the task is presented in the UI. */ export interface TaskPresentationOptions { /** * Controls whether the terminal is cleared before executing the task. */ clear?: boolean; } </del> export enum RerunBehavior { reevaluate = 1, useEvaluated = 2,

Related discussion:
text: This clear option can be into the exiting task property and would be called : { "label": "ExampleTask", "type": "shell", "command": "echo hello", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": false } } Added to : / Controls how the task is presented in the UI. / export interface TaskPresentationOptions { …. / Controls whether the terminal is cleared before executing the task. / clear?: boolean; }
This doesn't work for me: I run it multiple times and see all the output, the terminal is never cleared.
Turns out that if the only presentation option set is clear, this doesn't work. Thanks for finding!
Code change:
"textCodeBlock.background": "#F8F8F8", "textLink.activeForeground": "#005FB8", "textLink.foreground": "#005FB8", <del> "textPreformat.foreground": "#3B3B3B", </del> <ins> "textPreformat.foreground": "#A31515", </ins> "textPreformat.background":	"#0000001F", "textSeparator.foreground": "#21262D", "titleBar.activeBackground": "#F8F8F8",

Related discussion:
text: Expected ! Actual !
Regressed in
The markdown preview in the chat is also broken for Dark Modern but is fixed by your change: !
And the markdown preview in the settings editor: !
I looked into this some more and have the following findings block rendering is broken for Dark Modern, Light Modern, Dark HC and Light HC What changed: we a new theme token, , adopted it in and , and updated the values for to look good with a different background color But we didn't adopt token for blocks in Markdown previews, which is why is broken for Markdown preview Some options Adopt for blocks in Markdown preview -- this amounts to a rather drastic styling change for Markdown previews ! Revert Revert the change to and drop the usage of so that Markdown preview, chat, and settings UI are in a reasonable state for all themes, which I attempted in
Also affects the Extensions Details page since it is a Markdown preview !
Verification: for Light/Dark Modern and Light/Dark HC, make sure that blocks are properly rendered in Markdown preview, settings UI and chat
Code change:
} const { result } = await this.dialogService.prompt<ImportProfileChoice>({ type: Severity.Info, <del> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileTemplate.name), </del> <ins> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileName), </ins> buttons: [ { label: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Overwrite"),

Related discussion:
text: <!-- 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. --<!-- 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: 1.76 Steps to Reproduce: Exported a user profile using the GitHub gist link . The user navigates to the link in their browser, where they enter , and the profile opens in the explore view. At the same time, the profile badge is to the settings icon prior to importing the profile. If the user clicks "Import Profile", they are prompted to overwrite an existing profile. The user has never imported a profile prior to this experience. !
thanks for great repro steps. I can nicely reproduce. Assigning to since it seems like the Profile got applied to before hitting the import button, and hitting the import would double-import.
thanks for fixing can you try with latest Insiders and if it works fine you can add the label. Thanks!
Verified, however the profile badge gets to the Settings icon and to the Profiles list prior to importing the profile, but if you click "Import Profile" it imports as expected. Is this as expected? My assumption was that those would not show up until the Profile is imported. !
Yes. This is to indicate user that the profile is applied in preview mode.
Code change:
private _removeCellDecoration(decorationId: string) { const options = this._resolvedCellDecorations.get(decorationId); <ins> this._resolvedCellDecorations.delete(decorationId); </ins> if (options) { <ins> for (const existingOptions of this._resolvedCellDecorations.values()) { // don't remove decorations that are applied from other entries if (options.className === existingOptions.className) { options.className = undefined; } if (options.outputClassName === existingOptions.outputClassName) { options.outputClassName = undefined; } if (options.gutterClassName === existingOptions.gutterClassName) { options.gutterClassName = undefined; } if (options.topClassName === existingOptions.topClassName) { options.topClassName = undefined; } } </ins> this._cellDecorationsChanged.fire({ added: [], removed: [options] }); <del> this._resolvedCellDecorations.delete(decorationId); </del> } }

Related discussion:
text: Steps to Reproduce: a notebook with a markdown cell that has multiple headers e.g. the preview for the markdown cell - shift+enter symbols quickpick ctrl+shift+o and arrow down through the symbols list :bug: cell decoration appears for the first item but then is removed for the second
Code change:
} private _isDisposed = false; <ins> private _isReadonly = false; </ins> constructor( readonly viewType: string,

Related discussion:
text: Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by
Code change:
} } }); <ins> this.threads.forEach(t => { // Remove all old threads which are no longer part of the update #75980 if (threadIds.indexOf(t.threadId) === -1) { this.threads.delete(t.threadId); } }); </ins> const stoppedDetails = data.stoppedDetails; if (stoppedDetails) {

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.35.1 (also tried current 1.36.0-insider) OS Version: Ubuntu 18.04 VSCode's view seems to show all threads that ever existed, not just the ones returned by latest request. Repro: and run mock-debug extension from this branch: the folder and start configuration. all threads in the thread list and start stepping line by line. After each step the adapter will reduce the number of active threads by one. requests for invalid thread ids will be failed. By line 5, there will be only one thread remaining, yet VSCode tries to display all 5.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.586 --- <!-- score: 0.462 --- <!-- score: 0.461 --- <!-- score: 0.461 --<!-- potentialduplicatescomment --
make sure that only the threads returned by the last thread request (plus additional threads coming reported via the "thread" event) are shown.
thanks for the nice repo steps. I have changed that we now always respect the request as the absolute truth. So if a thread is not returned as part of the response we will delete it. I have created a PR which tackles this and I will merge this PR in next week since now we are in endgame and I would like to get more insiders coverage so we catch potential extensions which might rely on the current bugy behavior.
Code change:
}, "autoCloseBefore": ";:.,={}])>` nt$", "wordPattern": { <del> "pattern": "(p{Alphabetic}|p{Number}|p{Nonspacing_Mark}){2,}", </del> <ins> "pattern": "(p{Alphabetic}|p{Number}|p{Nonspacing_Mark}){1,}", </ins> "flags": "u" } }

Related discussion:
text: <!-- 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 <!-- 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. --- Version: 1.74.2 (user setup) Commit: Date: 2022-12-20T10:29:14.590Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a snippet for latex that uses $TMSELECTED_TEXT. The following is an example that wraps selected text in auto-sized brackets: 'lr' over a selected text and hit TAB. The selected text is not included in the output. ! F1 + Insert Snippet, however, produces the desired output. I have only encountered the problem in latex environment, including inline math in markdown files. The issue was raised in and was fixed in 1.73 update via (I think). But came back in 1.74.
The problem is the which requires two characters to be typed... This is what happens overtyping happens, we capture the overtyped text, and "await" the next suggest session to start this doesn't happen because suggest only auto starts at word ends and a single character is no word the next character is typed, erasing the overtyped, captured value suggest starts because the 2nd character makes this a word looping you in here and wonder if you know why such a word definition was chosen and if it can be changed
I don't know why the definition specifies 2 characters.