jiebi/CodeConvo huggingface dataset:
Code change:
const err = new Error('An extension called process.crash() and this was prevented.'); console.warn(err.stack); }; <ins> // Set ELECTRON_RUN_AS_NODE environment variable for extensions that use // child_process.spawn with process.execPath and expect to run as node process // on the desktop. // Refs https://github.com/microsoft/vscode/issues/151012#issuecomment-1156593228 process.env['ELECTRON_RUN_AS_NODE'] = '1'; </ins> } interface IRendererConnection {

Related discussion:
text: Testing <img width="348" alt="image" src="https://user-"
Extension fails to launch child_process during initialization Will check if the issue is isolated to this extension with a minimal example using module
Was able to isolate the issue, firstly as pointed above the extension makes an attempt to launch a child process via the helper which basically emulates options and passes them eventually into Since variant relies on when node executable path is not provided, this will default to use the Electron executable that is used to create the extension host. Now there are two problems with this usage, (i) execa module will not add the env variable, so the exectuable cannot be launched as intended. (ii) We also disable calling Electron executable as unless flag is provided in the call site. For the (ii) we automatically add the flag at both and callsites internally in the runtime, so this should not be a concern for the extension authors. As for (i), if the extension author used the vanilla then the env variable would be set internally by the runtime. But since the call is done via a 3rd party module, I think it is upto the extension authors to ensure the env variable is provided if they rely on the Electron executable. I feel like there is no action required from runtime/VSCode core for this issue, but we should loop in the extension author to fix this on their end. Thoughts ?
So what exactly is different in the utility process vs. child process today? I did not fully understand.
When extension host is created via , internally the runtime would launch the process with env variable set and we never remove this variable explicitly in the extension host after launch (i-e) , this would indirectly help above scenarios since the env gets inherited by extensions. This is not the case with utility process since there is no runtime induced env variable, the extensions have to explicitly add them if they rely on the electron executable. I would say the previous behavior was a hidden bug and is visible now with the utility process api.
Oh yeah understood! I think I somewhat agree that we need to just document this to extension authors.
btw, since this is a public issue, I've shared it with the dendron extension author directly to track
hey, dendron author here. thanks for looping us in on this. so as I understand, we have two options: either use vanilla or set when using the module.
Code change:
const err = new Error('An extension called process.crash() and this was prevented.'); console.warn(err.stack); }; <ins> // Set ELECTRON_RUN_AS_NODE environment variable for extensions that use // child_process.spawn with process.execPath and expect to run as node process // on the desktop. // Refs https://github.com/microsoft/vscode/issues/151012#issuecomment-1156593228 process.env['ELECTRON_RUN_AS_NODE'] = '1'; </ins> } interface IRendererConnection {

Related discussion:
text: is this an accurate understanding?
yup that is correct. To clarify, only when ends up using on the desktop extension host.
Got it. What's the timeline for us patching this? Is this already live in insider?
The change is not default in insiders yet, it is currently behind an environment variable , can give more context on the timeline.
after discussing with the team, we have decided to push a workaround in core to avoid breaking the extension community with the new process type for extension host. You don't need to make the adjustments outlined in
Code change:
*--------------------------------------------------------------------------------------------*/ import { Event } from 'vs/base/common/event'; <del> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, VIEWLET_ID, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDisposable, dispose } from 'vs/base/common/lifecycle'; </ins> import { IProgressService, ProgressLocation } from 'vs/platform/progress/common/progress'; <del> import { dispose, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, IDebugSession, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IViewsService } from 'vs/workbench/services/views/common/viewsService'; <del> import { NotificationPriority } from 'vs/platform/notification/common/notification'; </del> export class DebugProgressContribution implements IWorkbenchContribution {

Related discussion:
text: I am writing a debugger adapter. I use ProgressStartEvent/ProgressUpdateEvent/ProgressEndEvent to report some debug opertions' progress information. In previous versions, the progress information was shown in right-bottom corner, however, in 1.86.0, the progress information is shown in status bar instead. I think this is not a good idea, as user might not be able to notice the progress information. If there is a workaround if I still want to show progress information in right-bottom corner of VS code? Thanks! Bill Zhang
I haven't yet found a 1.86 commit that specifically changes this behaviour. Have you perhaps been trying out this new 1.86 feature?
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
The progress information was shown in status bar, not a pop-up window as before versions, so I have no way to enable/disable notification. In addition, notification was shown as before in right-bottom corner.
85 does not have this issue.
If you cannot find the actual commit causing this using , then you need to provide a minimal repro for us to try out.
Code change:
*--------------------------------------------------------------------------------------------*/ import { Event } from 'vs/base/common/event'; <del> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, VIEWLET_ID, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDisposable, dispose } from 'vs/base/common/lifecycle'; </ins> import { IProgressService, ProgressLocation } from 'vs/platform/progress/common/progress'; <del> import { dispose, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, IDebugSession, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IViewsService } from 'vs/workbench/services/views/common/viewsService'; <del> import { NotificationPriority } from 'vs/platform/notification/common/notification'; </del> export class DebugProgressContribution implements IWorkbenchContribution {

Related discussion:
text: I have tried the vscode-bisect, but it failed: PS C:gitBIOSDBGV4srcextensionnpx --yes --reset [build] deleting cache directory C:UserszhiqzhanAppDataLocalTempvscode-bisect √ Commit of released insiders build that reproduces the issue (leave empty to pick the latest build) ... √ Commit of released insiders build that does not reproduce the issue (leave empty to pick the oldest build) ... [build] fetching all builds from [build] total 171 builds with roughly 7 steps [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.85.0-insider... [build] starting desktop build ... √ Is good or bad? » Good [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.86.0-insider... [build] starting desktop build ... √ Is good or bad? » Bad [build] downloading build from [error] Error: read ECONNRESET You can run vscode-bisect --verbose for more detailed output and vscode-bisect --reset for a fresh start without caches.
At first, it is quick in downloading vscode-insider, but later it takes a long time to download it. I am not sure why. !
thanks a lot for trying it though, maybe some connection trouble. I can try it if you tell me how to reproduce.
I create a simple debugger for testing. code: vsix: I am not sure whether you know how to start a debugger or not: 1) install test-debugger- 2) open a empty folder and then create a ! 3) select Debugger For Test ! 4) Start Testing debugger ! 5) You will see progress information in status bar !
If run in 1.85.2, it is as below: !
thanks! Is it possible that you have snoozed notifications either globally or for the extension?
Code change:
*--------------------------------------------------------------------------------------------*/ import { Event } from 'vs/base/common/event'; <del> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, VIEWLET_ID, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDisposable, dispose } from 'vs/base/common/lifecycle'; </ins> import { IProgressService, ProgressLocation } from 'vs/platform/progress/common/progress'; <del> import { dispose, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, IDebugSession, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IViewsService } from 'vs/workbench/services/views/common/viewsService'; <del> import { NotificationPriority } from 'vs/platform/notification/common/notification'; </del> export class DebugProgressContribution implements IWorkbenchContribution {

Related discussion:
text: You effectively see the same notification but when it appears in the status bar, it means the notification is hiding because of the "Do not disturb mode". When you click the status bar entry you can see how it changes to the notification toast.
Yes, you are right. But even in below setting (BIOSDBG V4 is my extension): ! The notification is hidden unless you click the right-bottom icon. ! I think it makes me confused and it is not easy for user to notice this. Thanks!
There is indeed a change that happened as part of our latest release, but I think for the better: debug had always decided to show notifications for debug progress in the status bar via this directive: A change I did last milestone actually made to support it now: So I am deferring to debug component to further triage, but I think this is actually expected behaviour.
I think we should revert to the old behavior for consistency as that's what users have historically seen
Code change:
} private _updateContentsDomNodeMaxDimensions() { <del> const width = Math.max(this._editor.getLayoutInfo().width * 0.66, 500); const height = Math.max(this._editor.getLayoutInfo().height / 4, 250); </del> <ins> const height = Math.max(this._editor.getLayoutInfo().height / 4, 250, ContentHoverWidget._lastDimensions.height); const width = Math.max(this._editor.getLayoutInfo().width * 0.66, 500, ContentHoverWidget._lastDimensions.width); </ins> this._setContentsDomNodeMaxDimensions(width, height); }

Related discussion:
text: Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.
Code change:
return ''; } <ins> private get selectedText(): string { const activeEditor = this.editorService.getActiveEditor(); if (activeEditor) { const editorControl = (<ICodeEditor>activeEditor.getControl()); if (editorControl) { const editorModel = editorControl.getModel(); const editorSelection = editorControl.getSelection(); if (editorModel && editorSelection) { return editorModel.getValueInRange(editorSelection); } } } return ''; } </ins> private getFilePath(): string { let input = this.editorService.getActiveEditorInput(); if (input instanceof DiffEditorInput) {

Related discussion:
text: Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs
Code change:
this.container.style.marginLeft = `${marginWithoutIndentation}px`; } <del> setWidgetMargins(position: Position, indentationWidth?: number): void { if (indentationWidth === undefined) { indentationWidth = this._calculateIndentationWidth(position); } </del> <ins> setWidgetMargins(position: Position): void { const indentationWidth = this._calculateIndentationWidth(position); </ins> if (this._indentationWidth === indentationWidth) { return; }

Related discussion:
text: I think we used to indent inline chat to the indentation level of the line: ! Steps: have an indented line press enter to be on an empty line (still indented) press to bring up inline chat
Code change:
this._domNode.domNode.height = height * ratio; const ctx = this._domNode.domNode.getContext('2d')!; ctx.clearRect(0, 0, this.width * ratio, height * ratio); <del> this._renderCanvas(ctx, this.width * ratio, height * ratio, scrollHeight * ratio, ratio); </del> <ins> this._renderCanvas(ctx, this.width * ratio, height * ratio, contentHeight * ratio, ratio); </ins> this._renderOverviewViewport(); }

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:
this._domNode.domNode.height = height * ratio; const ctx = this._domNode.domNode.getContext('2d')!; ctx.clearRect(0, 0, this.width * ratio, height * ratio); <del> this._renderCanvas(ctx, this.width * ratio, height * ratio, scrollHeight * ratio, ratio); </del> <ins> this._renderCanvas(ctx, this.width * ratio, height * ratio, contentHeight * ratio, ratio); </ins> this._renderOverviewViewport(); }

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:
private openAsBinary(input: FileEditorInput, options: ITextEditorOptions | undefined): void { <del> // Mark file input for forced binary opening input.setForceOpenAsBinary(); // Open in group (this.group ?? this.editorGroupService.activeGroup).openEditor(input, { </del> <ins> const defaultBinaryEditor = this.configurationService.getValue<string | undefined>('workbench.editor.defaultBinaryEditor'); const groupToOpen = this.group ?? this.editorGroupService.activeGroup; const editorOptions = { </ins> ...options, // Make sure to not steal away the currently active group // because we are triggering another openEditor() call // and do not control the initial intent that resulted // in us now opening as binary. activation: EditorActivation.PRESERVE <del> }); </del> <ins> }; // If we the user setting specifies a default binary editor we use that. if (defaultBinaryEditor && defaultBinaryEditor !== '') { this.editorService.replaceEditors([{ editor: input, replacement: { resource: input.resource, options: { ...editorOptions, override: defaultBinaryEditor } } }], groupToOpen); } else { // Mark file input for forced binary opening input.setForceOpenAsBinary(); // Open in group groupToOpen.openEditor(input, editorOptions); } </ins> } private async openAsFolder(input: FileEditorInput): Promise<void> {

Related discussion:
text: We don't want to officially have the hex editor be recommended for non-textual files, but what about a setting like that can be used to open a binary file in a given editor instead of showing the "binary file" message? ! I would love it if I could have all non-text files automatically opened in the hex editor.
To verify ensure the setting works as expected. Setting it to a custom editor should automatically have that editor be opened when a file is detected as binary.
Code change:
} private get centeredEditorAvailableSize(): number { <del> return this.silosSize[Position.ONE] - EditorGroupsControl.CENTERED_EDITOR_MIN_MARGIN * 2; </del> <ins> return this.dimension.width - EditorGroupsControl.CENTERED_EDITOR_MIN_MARGIN * 2; </ins> } private get centeredEditorSize(): number { <del> return Math.min(this.centeredEditorAvailableSize, this.centeredEditorPreferedSize); </del> <ins> return Math.min(this.centeredEditorAvailableSize, this.centeredEditorPreferredSize); </ins> } private get centeredEditorPosition(): number {

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD
Code change:
goMenuRegistration(); debugMenuRegistration(); tasksMenuRegistration(); <del> terminalMenuRegistration(); </del> if (isMacintosh) { windowMenuRegistration();

Related discussion:
text: We should also take out the "Terminal" menu when using the custom menu: ! //cc
pushed a fix for this only to the release branch. What we do for master is up for discussion. please verify once the build is out in 30 mins. Thanks
Thanks I didn't know about this code.
Code change:
this._widget?.inlineChatWidget.updateInfo(''); this._widget?.inlineChatWidget.updateToolbar(true); <del> this._activeSession.addExchange(new SessionExchange(this._activeSession.lastInput, response)); </del> <ins> this._activeSession?.addExchange(new SessionExchange(this._activeSession.lastInput, response)); </ins> this._ctxLastResponseType.set(response instanceof ReplyResponse ? response.raw.type : undefined); }

Related discussion:
text: use generate cell in notebooks make a request while the request is active press stop a bunch of errors are printed
It seems not wise at all to maintain my own *chatcontroller. I'd love to look into how do I ensure I reuse the most of Inline Chat Controller later.
Is the generate cell feature just with using ctrl+i from within a cell body? Not sure how I can trigger it.