jiebi/CodeConvo huggingface dataset:
Code change:
this.toDispose.push(this.debugService.getViewModel().onWillUpdateViews(() => this.updateInlineValuesScheduler.schedule())); this.toDispose.push(this.debugService.getViewModel().onDidEvaluateLazyExpression(() => this.updateInlineValuesScheduler.schedule())); this.toDispose.push(this.editor.onDidChangeModel(async () => { <del> const stackFrame = this.debugService.getViewModel().focusedStackFrame; const model = this.editor.getModel(); if (model) { this.applyHoverConfiguration(model, stackFrame); } </del> <ins> this.updateHoverConfiguration(); </ins> this.toggleExceptionWidget(); this.hideHoverWidget(); this._wordToLineNumbersMap = undefined; <ins> const stackFrame = this.debugService.getViewModel().focusedStackFrame; </ins> await this.updateInlineValueDecorations(stackFrame); })); this.toDispose.push(this.editor.onDidScrollChange(() => {

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/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. --I'm currently implementing hit conditions in vscode-php-debug. Xdebug has very limited conditions it supports and we need to signal the user if they typed something unsupported. If a breakpoint has such a condition we try to return that in the field in the setBreakpointResponse/body/breakpoints. There is the implementation line: I noticed that the message is only visible when hovering with the mouse over the unverified breakpoint and only when the DAP isn't in a running state. If the adapter is in a breakpoint, there is no indication why this breakpoint isn't valid. Steps to Reproduce: and build vscode-php-debug from branch . a PHP debug Optionally add under setting. a breakpoint with hit condition "blabla". breakpoint should be unverified, hovering over it should show the message. Messages exchanged until now: launchResponse initializedEvent setBreakpointsRequest (see full message below) setBreakpointsResponse setFunctionBreakpointsRequest setFunctionBreakpointsResponse setExceptionBreakpointsRequest setExceptionBreakpointsResponse configurationDoneRequest configurationDoneResponse threadsRequest threadsResponse () a PHP process that will cause the debug adapter to move into running state. Following messages will be exchanged: ThreadEvent () StoppedEvent () threadsRequest threadsResponse () stackTraceRequest stackTraceResponse threadsRequest threadsResponse () scopesRequest scopesResponse variablesRequest variablesResponse this point hovering over the unverified breakpoint will not show the message.
Code change:
this.toDispose.push(this.debugService.getViewModel().onWillUpdateViews(() => this.updateInlineValuesScheduler.schedule())); this.toDispose.push(this.debugService.getViewModel().onDidEvaluateLazyExpression(() => this.updateInlineValuesScheduler.schedule())); this.toDispose.push(this.editor.onDidChangeModel(async () => { <del> const stackFrame = this.debugService.getViewModel().focusedStackFrame; const model = this.editor.getModel(); if (model) { this.applyHoverConfiguration(model, stackFrame); } </del> <ins> this.updateHoverConfiguration(); </ins> this.toggleExceptionWidget(); this.hideHoverWidget(); this._wordToLineNumbersMap = undefined; <ins> const stackFrame = this.debugService.getViewModel().focusedStackFrame; </ins> await this.updateInlineValueDecorations(stackFrame); })); this.toDispose.push(this.editor.onDidScrollChange(() => {

Related discussion:
text: Full breakpoint messages Version: 1.59.0 (user setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: Windows_NT x64 10.0. Full log of message exchange (DAP and Xdebug)
Maybe a good issue to get introduced to the breakpoint message computation. Thus assigning to Code pointer where we compute breakpoint messages There is probably some check wrong depending on the debug state.
Any luck looking into this? I just want to check if there is something I did wrong before releasing. Btw: Is there any way to enable DAP logging of node/typescript adapter so I can compare messages?
we just did not have a chance to look into this yet. will probably look into it soon, if he is busy I can also help. Yes, it is possible to enable DAP logging for js-debug. Add to your and start debugging. The location of the log file on your disk will be written to the Debug Console. That log file should have the communication.
I totally lost this one, and it's fairly straightforward. This is due to us disabling editor hover in favor of the custom debug hover.
<!-- 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!
Code change:
import { CancellationToken } from 'vs/base/common/cancellation'; import { KeyCode } from 'vs/base/common/keyCodes'; import { Disposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; <del> import { Constants } from 'vs/base/common/uint'; </del> import { ContentWidgetPositionPreference, IActiveCodeEditor, ICodeEditor, IContentWidget, IContentWidgetPosition, IEditorMouseEvent, MouseTargetType } from 'vs/editor/browser/editorBrowser'; import { ConfigurationChangedEvent, EditorOption } from 'vs/editor/common/config/editorOptions'; import { Position } from 'vs/editor/common/core/position';

Related discussion:
text: ! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at
Code change:
error: message }); } <ins> private telemetryDebugAddBreakpoint(breakpoint: IBreakpoint, context: string): TPromise<any> { /* __GDPR__ "debugAddBreakpoint" : { "context": { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, "hasCondition": { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, "hasHitCondition": { "classification": "SystemMetaData", "purpose": "FeatureInsight" }, "hasLogMessage": { "classification": "SystemMetaData", "purpose": "FeatureInsight" } } */ return this.telemetryService.publicLog('debugAddBreakpoint', { context: context, hasCondition: !!breakpoint.condition, hasHitCondition: !!breakpoint.hitCondition, hasLogMessage: !!breakpoint.logMessage }); } </ins> }

Related discussion:
text: When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label
Code change:
processCallbacks.push(child => { child.stdout.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); child.stderr.on('data', (data: Buffer) => console.log(data.toString('utf8').trim())); return new TPromise<void>(c => child.once('exit', () => c(null))); }); } <ins> // If we are running with input from stdin, pipe that into a file and // open this file via arguments. let isReadingFromStdin: boolean; try { isReadingFromStdin = !process.stdin.isTTY; // Via https://twitter.com/MylesBorins/status/782009479382626304 } catch (error) { // Windows workaround for https://github.com/nodejs/node/issues/11656 } let stdinFilePath: string; if (isReadingFromStdin) { let stdinFileError: Error; stdinFilePath = paths.join(os.tmpdir(), `stdin-${Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 6)}.txt`); try { // Pipe into tmp file process.stdin.setEncoding('utf8'); process.stdin.pipe(fs.createWriteStream(stdinFilePath)); // Make sure to open tmp file argv.push(stdinFilePath); // Enable --wait to get all data argv.push('--wait'); args.wait = true; } catch (error) { stdinFileError = error; } if (args.verbose) { if (stdinFileError) { console.error(`Failed to create file to read via stdin: ${stdinFileError.toString()}`); } else { console.log(`Reading from stdin via: ${stdinFilePath}`); } } } </ins> // If we are started with --wait create a random temporary file // and pass it over to the starting instance. We can use this file // to wait for it to be deleted to monitor that the edited file

Related discussion:
text: There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.
Code change:
if (userDataProfileImportState.isEmpty()) { await importAction.run(); } else { <del> await this.showProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW, profileTemplate.name, importAction, new BarrierAction(barrier, new Action('cancel', localize('cancel', "Cancel"))), false, userDataProfileImportState); </del> <ins> await this.showProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW, profileTemplate.name, importAction, new BarrierAction(barrier, new Action('cancel', localize('cancel', "Cancel")), this.notificationService), false, userDataProfileImportState); </ins> } await barrier.wait(); await this.hideProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW);

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/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. --- VS Code Version: 1.76.0 OS Version: macOS 11.6.2 Version: 1.76.0 Commit: Date: 2023-03-01T10:23:45.993Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 20.6.0 Sandboxed: No Summary When creating a profile with a name such as "Typescript / Javascript", the following happens: When exporting as a Gist, no result dialog shows ("there was trouble" / "created profile successfully") and a validation error is outputted in the logs When exporting to a local file, the text after the last forward slash is set as the filename. With the above example, it'd be " " To reproduce: a profile: Settings cog -"Profile ([...])" the profile: Select "Export Profile..." -"Export" the "name the profile" step, enter a name with a forward slash in like so: "Typescript / Javascript" either method for exporting: gist or local Expected results: If you select local: a system save prompt with the name you entered pre-set in the filename field If you select gist: A success dialog with a link to the website prefilled with your config Actual results: If you select local: only the text after the last forward slash is in the filename field If you select gist: No dialog shows.
Code change:
if (userDataProfileImportState.isEmpty()) { await importAction.run(); } else { <del> await this.showProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW, profileTemplate.name, importAction, new BarrierAction(barrier, new Action('cancel', localize('cancel', "Cancel"))), false, userDataProfileImportState); </del> <ins> await this.showProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW, profileTemplate.name, importAction, new BarrierAction(barrier, new Action('cancel', localize('cancel', "Cancel")), this.notificationService), false, userDataProfileImportState); </ins> } await barrier.wait(); await this.hideProfilePreviewView(IMPORT_PROFILE_PREVIEW_VIEW);

Related discussion:
text: The following error is in the "output" window, under "Window": I can only test this on a macOS device, I haven't tried this on a Windows or other Linux device and I feel like (with the area in mind - filesystems etc) these issues could manifest differently or not even be an issue there. I'm assuming validation on the inputbox for the name will be required because filesystems (and Gist? not sure) don't typically support forward slashes in file names. Thanks and if you're reading this, have a great weekend :)
Gists do no accept in the name. Replaced with .
Code change:
} })); <del> const progressBar = new ProgressBar(container, this.styles.progressBar); progressBar.getContainer().classList.add('quick-input-progress'); </del> const focusTracker = dom.trackFocus(container); this._register(focusTracker); this._register(dom.addDisposableListener(container, dom.EventType.FOCUS, e => {

Related discussion:
text: I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)
Code change:
"dependencies": { "applicationinsights": "1.0.8", "chokidar": "3.5.1", <ins> "eslint-plugin-header": "3.1.1", </ins> "graceful-fs": "4.2.6", "http-proxy-agent": "^2.1.0", "https-proxy-agent": "^2.2.3",

Related discussion:
text: Currently, we have to add this copyright header manually to every new file: /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ An ES Lint rule that has an auto fix would be really nice. What are your thoughts ! (using )
I like. The closest that we have today is this snippet
Let's do it!
Code change:
id: SelectionToWatchExpressionsAction.ID, label: SelectionToWatchExpressionsAction.LABEL, alias: 'Debug: Add to Watch', <del> precondition: ContextKeyExpr.and(EditorContextKeys.editorTextFocus), </del> <ins> precondition: ContextKeyExpr.and(CONTEXT_IN_DEBUG_MODE, EditorContextKeys.editorTextFocus), </ins> contextMenuOpts: { group: 'debug', order: 1

Related discussion:
text: The change for went in without a UX discussion. IMHO we should reconsider adding these two actions to all editor context menus. IMHO we need to be more critical with adding things there and have good reasons to do so. <img width="284" alt="image" src="https://user-"
I figured it wasn't a major change since they are already in the context menu during a debug session. Would a Debug submenu help? Or how about only showing them if the user has previously debugged in this workspace?
I see how it might not feel like a major change, but IMHO we should approach this with a different mindset. We have many useful commands, and we can add many of them to the context menu, but just because we have the ability to add them is not IMHO a good enough reason. Adding something to the context menu has two disadvantages: it makes our editor feel bloated (think typical IDE of the early 00s) it detracts from the value of the existing items, since there are so many of them. I think we need to have a good reason to decide to always show something in the context menu, like a very important feature that we feel will differentiate VS Code from other editors, a reaction to a lot of user feedback, an action which would make the product incomplete if it would be missing, etc.
We discussed this in standup and I will likely just remove them when not in a debug session.
From and Keeping the changes so that they will work and appear in the command palette when not in a debug session, but only appear in the editor context menu while debugging
Code change:
rows: 30 }); instantiationService.stub(IStorageService, new TestStorageService()); <del> instantiationService.stub(ITerminalContributionService, { quickFixes: [] } as Partial<ITerminalContributionService>); </del> <ins> instantiationService.stub(ITerminalContributionService, { quickFixes: new Promise((r) => { r([]); }) } as Partial<ITerminalContributionService>); </ins> instantiationService.stub(ITerminalQuickFixService, { onDidRegisterProvider: new Emitter().event, onDidUnregisterProvider: new Emitter().event, onDidRegisterCommandSelector: new Emitter().event } as Partial<ITerminalQuickFixService>); instantiationService.stub(IConfigurationService, new TestConfigurationService()); instantiationService.stub(ILabelService, {} as Partial<ILabelService>);

Related discussion:
text: Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-