jiebi/CodeConvo huggingface dataset:
Change:
* A string to show as placeholder in the input box to guide the user. */ placeholder: string; <ins> /** * Controls whether the input box is visible (default is `true`). */ visible: boolean; </ins> } interface QuickDiffProvider {

Discussion:
my SCM extension has no use for the input box, so after creating its instance using scm.createSourceControl I want to set .inputBox.visible=false But visible is only defined in so I get this error reported when I save my change: It seems the property first got introduced by but that caused a problem and had to be reverted on 24-Oct-2018 by , which in turn was reverted later the same day by It passed testing on 30-Oct-2018 under More recently (4-Oct-2019) (still open) has made use of the visible property despite still only being proposed. Perhaps it can do this because it's the built-in Git SCM rather than an extension. Can this API be finalized soon?
Yeah let's try to move it along.
Sorry, but had to push this forward to March. Will get it done as soon as the milestone starts.
No worries and thanks for the update.
Ufff... I forgot I'll be out in March (paternity leave!) so have to push to April, sorry about that!
no worries. I hope your own personal March endgame goes really well
Change:
} else { await this.raw.disconnect(restart); } <ins> if (!restart) { this._options.compoundRoot?.sessionStopped(); } </ins> } /**

Discussion:
Ever since I started using the new JS debugger, when running our top level target and then manually closing the code-oss window, the and targets remain: ! Eventually, maybe 1 minute later, the goes away, but the other one stays, I always have to manually disconnect from it. ! cc
This is because is set for the shared process and extension host, which allows them to reconnect when vscode is reloaded. Eventually js-debug in extension host gives up, but the shared process is using the previous Node debugger which doesn't give up. Both these are working as designed, this is kind of a downside of the compound launch configs in that there's no "compound stop".
Yeah, would actually LOVE a compound stop. Could this be a feature of compounds, & Meaning, if something like was set in the compound, all targets would share the same action, and I would see no actions.
We could add a attribute to the compound, however how would that work? Clicking stop on any of the compound sessions would send stop to all sessions? And it would never be rendered as dicsonnect?
Maybe compound launch configs could have a pseudo-root, which has a "stop" action that affects all individual configs? ` The compound config could have an option whether sessions can be stopped individually, or whether stopping one session is treated as stopping the whole set of configuration.
ok makes somewhat sense, the flaw of my proposel is that once compound starts 4 sessions those sessions are not related in any way. So adding a pseudo root might be smart. The pseudo root would not be rendered, and the pseudo root would remember the attribute. Here are code pointers for a PR. We should add the attribute and to the schema . Code pointer for the debug session to add the pseudo root stopAll smartness
I like both options.
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Please let's have the bot not do this for ourselves.
BTW, the bot's wording sounds wrong: in to the latest...
Much better, and I this attribute to our compound config. But the behavior partly confuses me and I opened
Change:
export function validateTerminalName(name: string): { content: string, severity: Severity } | null { if (!name || name.trim().length === 0) { return { <del> content: localize('emptyTerminalNameError', "A name must be provided."), severity: Severity.Error </del> <ins> content: localize('emptyTerminalNameInfo', "Providing no name will reset it to the default value"), severity: Severity.Info </ins> }; }

Discussion:
Testing a terminal tab title setting your terminal to "foo" to set the name to blank string to, but I would expect it to just use my default from 1.
We discussed this and want to require a title.
I don't mean that blank titles should be allowed. I more meant how do I get back to the default I set in settings after I renamed the terminal, I feel I would expect it to let me delete my custom name and then it would use the default
You can reset the setting by clicking on the gear - is that what you mean?
No I meant is there a way to reset the terminal title to be the value of my setting instead of my custom named one?
We currently don't support going backward like that. I'll appropriately rename this issue for more discussion in October because I also wondered about this and discussed it with
Thanks sorry if I wasn't clear . My suggested UX would just be to have that be the default if you were attempt to have a blank name
oh - yes Brigit caught that case and I fixed it. so if it's set to '' or 'any number of spaces', it'll now show the process name. might've misunderstood what you were saying
But shouldn't it show whatever my setting states the default is rather than just the process name?
Sorry, the difference between our issues is she is talking about the setting I'm talking about the terminal title itself and not the setting. I want a blank rename of a terminal to reset to the value of my setting
I thought your setting was set to ''
confused - you can't set it to blank. we don't allow that
!
So my request is if my setting is and I name a terminal "foo". How do I reset "foo" back to the value of . My suggestion was that if you attempted to submit a blank name that would automatically reset to the value of your setting.
yep the name of this issue now reflects that. we'll see what says about that.
and I discussed it and it makes sense to do this
Change:
} } <ins> export function compareBulkFileOperations(a: BulkFileOperation, b: BulkFileOperation): number { return compare(a.uri.toString(), b.uri.toString()); } </ins> // --- ACCESSI export class BulkEditAccessibilityProvider implements IListAccessibilityProvider<BulkEditElement> {

Discussion:
Testing With all the files in the multi-diff editor collapsed to make it easy to see: ! To repro, try to rename this:
I see, that's a good point thanks!
To verify: Do a rename but do not accept rename Click on The refactor preview should open Open the multi diff editor from there by clicking on any change in the refactor preveiw Check that the order of the files in the refactor preview matches the order of the files in the multi diff editor
Change:
// Restore Zen Mode if active and supported for restore on startup const zenConfig = this.configurationService.getValue<IZenModeSettings>('zenMode'); const wasZenActive = this.storageService.getBoolean(Workbench.zenModeActiveStorageKey, StorageScope.WORKSPACE, false); <del> if (wasZenActive && (zenConfig.restore || this.lifecycleService.startupKind === StartupKind.ReloadedWindow)) { </del> <ins> if (wasZenActive && zenConfig.restore) { </ins> this.toggleZenMode(true, true); }

Discussion:
zen mode vscode, start vscode that zen mode properly is not restored excepted centered layout. Centered layout should also be inactive (since is )
acutally your change from that commit caused this. You removed that the zen mode gets out of zen mode when you are exiting. Let me look into a fix
the idea is to only write to local storage from and not . Is writing any data to local storage? If not, this change seems fine.
it is writing data to local storage. I just need to write it before the workbench goes down. So I will react on instead of . That event will only get fired once before the workbench shuts down?
yeah currently that is right. In the future when we decide to store state more periodically we might decide to call this method more often though to preserve state even if Code is crashing. I do not understand why you have to leave Zen mode on shutdown because you will restore it on the next startup, no? Given that, I suggest to NOT leave Zen mode on shutdown but rather simply NOT restore it on next startup. Isn't that easier?
thanks for clarification. I can not simply NOT restore it on next startup since the subsets of zen mode will have written state to storage. Example: User enters zen mode -zen mode tells Sidebar hide yourself. Sidebar writes that into storage Next vscode start -zen mode is not restored, Sidebar is still hidden because he wrote into storage once we activated zen mode. Due to how the feature is designed it needs to explicitly tell the underlying parts to hide or show. We could change this, but that would require that every underlying part is aware of zen mode which might overcomplicate things. Suggestions on how to tackle this are also welcome Thanks
got it. I pushed a change so that carries a with a reason you can ask for. On shutdown that reason will be set and so you can do the same things as before. As long as you are not running async code that accesses storage late, things should be fine. The goal should be that storage layer gets accessed either: when changes happen (e.g. workbench layout does that) or (which currently only fires on shutdown but might fire periodically later)
this works.

However there was a corner case for the reload since we were restoring zen mode always on reload and in your event i was not getting if it is a reload or regular shutdown Though fixed it by not auto restoring zen mode on reload. I think this is perfectly fine. Users should set zenMode.restore to true if they want this
thank you
Change:
/** * Adds a status to the list. <ins> * @param status The status object. Ideally a single status object that does not change will be * shared as this call will no-op if the status is already set (checked by by object reference). </ins> * @param duration An optional duration in milliseconds of the status, when specified the status * will remove itself when the duration elapses unless the status gets re-added. */

Discussion:
Just saw , this goes against the design. It's meant to only add the status if it doesn't already exist, if the status changed then it should use a different id and/or remove the old status first.
I'm not clear on the solution. There're a limited number of Terminal Status IDs: In this case status ID hasn't changed, it's still , only the description which comes with it has updated.
working on it, I'll send a PR to you in a bit
Validate still doesn't happen.
Change:
import { remotePtyHostLog, remoteServerLog, sharedLogChannelId, userDataSyncLogChannelId } from 'vs/workbench/contrib/logs/common/logConstants'; import { LogLevelChannelClient } from 'vs/platform/log/common/logIpc'; import { IRemoteAgentService } from 'vs/workbench/services/remote/common/remoteAgentService'; <ins> import { LOG_CHANNEL_ID as remoteTunnelLogChannelId } from 'vs/platform/remoteTunnel/common/remoteTunnel'; </ins> export class LogLevelService extends CommonLogLevelService {

Discussion:
In the shared service, in , I create a logger () and listen to it for log level changes: In the renderer, that logger that log file is registered to a channel with the name When I open the command and pick and change the level, I don't get a change event in the shared service as I would have expected. Shouldn't that work?
Change:
resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.22: version "0.9.0-beta.22" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.22.tgz#18f2eabda82709cdd64dee003879b586869e28a3" integrity sha512-1I8W0bwjg6bUoNaESKHSkS9BN3Z9Xe44/zbUb6Un+pbb5Nun4LQvFwSLkAIdRrslxcbcHYIU/2Q7F1wCOWLbaA== </del> <ins> xterm-addon-search@0.9.0-beta.23: version "0.9.0-beta.23" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.23.tgz#3f568afaddbb2cb9bb13a80deada6a3715a10172" integrity sha512-kKOyOf+9ERam6IGjV5LTQJTIL6HaiecZkMcrckMY9fUyH53+kknNMfGoBmMgDXWTe8WjBdyTtiqr120koDUKVQ== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3"

Discussion:
Testing macOS, zsh Do a couple of ls calls for something that has multiple matches in the terminal using the Down or Up arrow -notice how the count is always wrong !

Testing Notice how the "no results" is grey in the editor when the find input is empty. In the terminal it is red !

Refs: macOS, zsh shell Search for something in the terminal that does not exist -"no results" is not rendered. !

Testing a new terminal a script which logs the same text 2000 times a query, find widget says there are 2000 matches the terminal (e.g. collapse and expand the side bar) :bug: the number of matches is now less even though the same amount of scrollback is visible, moreover deleting and reentering the query doesn't reset the match count !
Maybe this isn't released yet, but I'm still getting the same problem in today's insiders.
Still repros for me :(
Can one of you pls provide a gif? it's working for me with the above example as expected and with others
https://user-
You are both on Windows - I wonder if that has to do with this. Could someone on mac pls verify this?
!
from !
Something weird going on here: ! This is after pasting in " Hi Hi" many times, once the command wraps to the end the terminal freaks out (conpty reprinting), but at some point it breaks and find only finds one result. Finding the next works, but it still says 1 of 1.
More weird behavior !
All results aren't getting included when search results get highlighted !
Problem here seems to be the search addon gets confused because translateToString considers the second character whitespace: But in the search algorirthm it's treated as a null character, of length 0, as opposed to .
Still reproing this. Initially: ! After making the terminal panel taller: !
this is on Windows? That's actually acting as expected because of the way conpty works, it ends up losing lines just above the bottom of the buffer.
Pretty sure you were seeing so closing this again for verification

Testing a query which results in matches the terminal (e.g. expand or collapse explorer) :bug: match decorations remain !
Change:
this._register(this.registerPart(this.mainPart)); this.registerActions(); <ins> this.registerAPICommands(); </ins> } protected createMainTitlebarPart(): BrowserTitlebarPart {

Discussion:
Currently, allows several variables. It would be awesome for extensibility, if would be supported, with being an arbitrary context variable. Then extensions could contribute to the window title (candidates would be or ). I'd be up to create a PR! Related:
Sounds interesting, feel free to give it a try. The variables are substituted from here:
anyone assign me pls
Verification steps: an extension, create a contxt key and register a title variable to in settings and add the newly created title variable (for example ) sure the window title correctly renders the value of the variable in the command center / window title area
Change:
['tree', 'editor'] as const, { enumDescriptions: [ <del> nls.localize('peekWidgetDefaultFocus.tree', "Focus the tree when openeing peek"), </del> <ins> nls.localize('peekWidgetDefaultFocus.tree', "Focus the tree when opening peek"), </ins> nls.localize('peekWidgetDefaultFocus.editor', "Focus the editor when opening peek") ], description: nls.localize('peekWidgetDefaultFocus', "Controls whether to focus the inline editor or the tree in the peek widget.")

Discussion:
The configuration peekWidgetDefaultFocus has it's description mispelled on Settings screen. It shows openeing when the correct is opening. I'll make a pull request to fix this. Version: 1.42.0-insider Commit: Date: 2020-01-29T05:36:49.901Z Electron: 6.1.6 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Linux x64 5.3.0-29-generic Steps to Reproduce: settings for 'Peek Widget Default Focus'. ! Does this issue occur when all extensions are disabled?: Yes
Change:
DOM.hide(this.templateData.outputShowMoreContainer.domNode); } <del> const editorHeight = this.templateData.editor.getContentHeight(); this.viewCell.editorHeight = editorHeight; </del> this._relayoutCell(); // if it's clearing all outputs, or outputs are all rendered synchronously // shrink immediately as the final output height will be zero.

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. -- It seems the cell heights are not updated properly when clearing outputs of cells that are not visible.
I had trouble reproing the original issue, but I also can't repro in insiders so marking verified.
Change:
'properties': { [customEditorsAssociationsKey]: { type: 'array', <del> markdownDescription: nls.localize('editor.editorAssociations', "Configure which editor to use for a resource."), </del> <ins> markdownDescription: nls.localize('editor.editorAssociations', "Configure which editor to use for specific file types."), </ins> items: { type: 'object', <ins> defaultSnippets: [{ body: { 'viewType': '$1', 'filenamePattern': '$2' } }], </ins> properties: { 'viewType': { type: 'string', <del> description: nls.localize('editor.editorAssociations.viewType', "Editor view type."), }, 'mime': { type: 'string', description: nls.localize('editor.editorAssociations.mime', "Mime type the editor should be used for. This is used for binary files."), </del> <ins> description: nls.localize('editor.editorAssociations.viewType', "The unique id of the editor to use."), </ins> }, 'filenamePattern': { type: 'string', <del> description: nls.localize('editor.editorAssociations.filenamePattern', "Glob pattern the editor should be used for."), </del> <ins> description: nls.localize('editor.editorAssociations.filenamePattern', "Glob pattern specifying which files the editor should be used for."), </ins> } } }

Discussion:
Issue Type: <bBug</bBug does not provide a default setting snippet has a property that is no longer used VS Code version: Code - Insiders 1.44.0-insider (, 2020-04-03T22:09:44.908Z) OS version: Darwin x64 19.3.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
export const inDiffEditor = new RawContextKey<boolean>('inDiffEditor', false, nls.localize('inDiffEditor', "Whether the context is a diff editor")); export const isEmbeddedDiffEditor = new RawContextKey<boolean>('isEmbeddedDiffEditor', false, nls.localize('isEmbeddedDiffEditor', "Whether the context is an embedded diff editor")); export const inMultiDiffEditor = new RawContextKey<boolean>('inMultiDiffEditor', false, nls.localize('inMultiDiffEditor', "Whether the context is a multi diff editor")); <ins> export const multiDiffEditorAllCollapsed = new RawContextKey<boolean>('multiDiffEditorAllCollapsed', undefined, nls.localize('multiDiffEditorAllCollapsed', "Whether all files in multi diff editor are collapsed")); </ins> export const hasChanges = new RawContextKey<boolean>('diffEditorHasChanges', false, nls.localize('diffEditorHasChanges', "Whether the diff editor has changes")); export const comparingMovedCode = new RawContextKey<boolean>('comparingMovedCode', false, nls.localize('comparingMovedCode', "Whether a moved code block is selected for comparison"));

Discussion:
We have a "collapse all" button: And other places in vscode this typically toggles to an "expand all". Would make sense to have it here as well
PR is now available for review
Change:
if (!Array.isArray(completionList)) { completionList = [completionList]; } const completions = completionList.map((e: any) => { return new SimpleCompletionItem({ label: e.ListItemText,

Discussion:
Steps to Reproduce: and press :bug: intellisense completion was for the argument instead of running the command I have a pretty strong muscle memory to run that command, so now I need to remember to press escape before pressing enter !
this is bad enough that I've turned the feature off, I can't even use
I also hit these issues particularly with : ! !
one change that would make this much less painful: ctrl+z should undo the auto-complete change as a single action (as is the case with the text editor). I press enter really quickly, after typing what I want, and if auto-complete provides something I didn't want, ctrl+z will undo one character at a time.
Well powershell does support ctrl+z itself. We may be able to undo everything, or nearly everything by using bracketed paste mode, since you can paste something and undo it fine.
Just tried with Posh-Git and while the commands () and aliases ( in mine) work, it still doesn't suggest after checkout: <img width="859" alt="Screenshot 2024-06-14 at 9 56 45 AM" src=""
doesn't show files/folders so we couldn't use that. Maybe using the current completion call, but also providing , , etc. when there are only and entries?
Looks promising <img width="861" alt="Screenshot 2024-06-14 at 10 11 11 AM" src=""
Change:
return { command: { command: 'git.publish', <del> title: localize('scm button publish title', "$(cloud-upload) Publish Branch"), </del> <ins> title: localize('scm publish branch action button title', "{0} Publish Branch", '$(cloud-upload)'), </ins> tooltip: this.state.isActionRunning ? localize('scm button publish branch running', "Publishing Branch...") : localize('scm button publish branch', "Publish Branch"),

Discussion:
The part of the button appears to be getting localized in the pseudo-language extension pack. !
Verified by code review.
Change:
run: yarn --frozen-lockfile --network-timeout 180000 - name: Compile and Download <del> run: yarn npm-run-all --max_old_space_size=4095 -lp compile "electron x64" playwright-install download-builtin-extensions </del> <ins> run: yarn npm-run-all --max-old-space-size=4095 -lp compile "electron x64" playwright-install download-builtin-extensions </ins> - name: Compile Integration Tests run: yarn --cwd test/integration/browser compile

Discussion:
Builds:
fyi
Attempting a fix by simply doubling the max memory available to V8.
Again in
Then I'm out of ideas. we might need to split all those mangling tasks into independent processes, if memory limits are being hit.
Are we sure that we are on the right track here? According to my counting (below) we have only a tenth of the code in extensions (compare to the src-folder) so I wonder why mangling would eat up so much memory here?
I am not sure OOM is the symptom here actually, just my best hunch, but it seems is indeed the problem: <img width="913" alt="image" src=""
Added a every 1 second log of memory usage to this task: Build running:
Created to log the memory usage after each mangling step
lol - similar idea here:
I think we are on to something here. The memory is growing a lot, maybe some state leaks when mangling the next extension. Each extension is its own tsconfig and mangling context. This shouldn't pile up but memory should be released inbetween
Can you take a look at this? I put my money on this which keeps its mangler around. Looks like we need some webpack hook to dispose that loader
I gave it a stab at for which I have confidence, running locally shows how memory is growing and shrinking! This isn't a webpack change but just some cleanup in the mangler itself
!