jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> async createTemporaryProfile(profile: IUserDataProfile, name: string, extensionsDisabled: boolean): Promise<void> { const userDataProfilesExportState = this.instantiationService.createInstance(UserDataProfileExportState, profile, extensionsDisabled); </del> <ins> async createTroubleshootProfile(): Promise<void> { const userDataProfilesExportState = this.instantiationService.createInstance(UserDataProfileExportState, this.userDataProfileService.currentProfile, true); </ins> try { <del> const profileTemplate = await userDataProfilesExportState.getProfileTemplate(name, undefined); await this.importAndSwitch(profileTemplate, true, true, extensionsDisabled, localize('import', "Create Profile")); </del> <ins> const profileTemplate = await userDataProfilesExportState.getProfileTemplate(localize('troubleshoot issue', "Troubleshoot Issue"), undefined); await this.progressService.withProgress({ location: ProgressLocation.Notification, delay: 1000, sticky: true, }, progress => this.importAndSwitchWithProgress(profileTemplate, true, true, true, message => progress.report({ message: localize('troubleshoot profile progress', "Setting up Troubleshoot Profile: {0}", message) }))); </ins> } finally { userDataProfilesExportState.dispose(); }

Related discussion:
text: Testing I started the Troubleshoot issue flow and it took a long time to create my initial profile. All I had was a status bar item which took me a while to discover (I actually thought something else went wrong). I would love to see and editor / web view better guiding me through that process by: listing the steps and adding check marks when done showing me the number of bisects still necessary giving me a final report.
<img width="258" alt="capture" src=""
We should also have a UI to always stop the process (see ) for a situation where this is useful
I now see that there is a notification for each step. This makes it better, so may be a simple thing to do is to show a notificatio with progress when the profile is created instead of a simple status bar item.
Actually, setting up the trouble shooting profile should be fast and instant.
Was not for me :-(
Following notification is shown now !
Code change:
import { VIEWLET_ID, ISCMRepository, ISCMService, VIEW_PANE_ID, ISCMProvider, ISCMViewService, REPOSITORIES_VIEW_PANE_ID } from 'vs/workbench/contrib/scm/common/scm'; import { KeyMod, KeyCode } from 'vs/base/common/keyCodes'; import { MenuRegistry, MenuId } from 'vs/platform/actions/common/actions'; <del> import { SCMStatusController } from './activity'; </del> <ins> import { SCMActiveResourceContextKeyController, SCMStatusController } from './activity'; </ins> import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions, ConfigurationScope } from 'vs/platform/configuration/common/configurationRegistry'; import { IContextKeyService, ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey';

Related discussion:
text: <!-- Do you have a question? Please ask it on --VSCode Version: 1.12.1 OS Version: OS X EI Capitan 10.11.3 Steps to Reproduce: some project from GitHub. a file A.cs which has no fresh changes at all. on the editor of A.cs, and notice the button of on the top right corner above the editor doesn't display as disbled! Clicking it has no effect of course, but it should display as disable in this case just like what in the old versions.
Can't fix without , closing for now.
since it connot be fixed without , should this be kept open and linked to then?
Sure.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!
Hoping to re-open this because I got this as a feedback item from a few CS educators. They notice their students clicking it accidentally and being confused when there is no apparent action.
I think this has regressed, I now miss this button when a file is staged.
Fixed regression with
There is another regression (), so I will be reverting this fix for this, and will refactor it.
Code change:
super(); this._standaloneColorPickerVisible.set(true); this._standaloneColorPickerParticipant = _instantiationService.createInstance(StandaloneColorPickerParticipant, this._editor); <del> this._position = this._editor._getViewModel()?.getPrimaryCursorState().viewState.position; </del> <ins> this._position = this._editor._getViewModel()?.getPrimaryCursorState().modelState.position; </ins> const editorSelection = this._editor.getSelection(); const selection = editorSelection ? {

Related discussion:
text: cursor is rendered on top of it <img width="400" src="https://user-"Version: 1.78.0 Commit: Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.78.0 Chrome/108.0.5359.215 Electron/22.4.8 Safari/537.36
Hi thank you for filing the issue. I tried to reproduce this issue, but it seems to work fine on my computer. Could you please try spawning a color picker in the latest VS Code Insiders (). If you continue seeing this issue, could you please try to run VS Code Insiders without any extensions and reproduce this error? It so happens sometimes that extensions cause errors. If you still see this issue, do you think you could copy paste below a minimally reproducible example of the contents of the editor where this happens?
<details</summary</details! Maybe it only reproduces with zoom? Should it render like that with markers? !
Hi, thanks for the reply, could you post here a copy of your settings file. I am thinking this error could be happening in relation to one of your settings.
Hmmm, it's a 2000 line-long file, not sure how useful it would be. It looks like I can reproduce it on the web with browser zoom and . On desktop that would be:
Code change:
}); } else { groupActiveEditorCanSplitInGroupContext.set(false); <del> sideBySideEditorContext.set(false); </del> <ins> groupActiveEditorIsSideBySideEditorContext.set(false); </ins> groupActiveEditorDirtyContext.set(false); }

Related discussion:
text: Reproduced on OSS, Mac Steps to Reproduce: Code OSS a file cmd+w Closes the window Bisect points to this commit -
I can reproduce and this is likely context keys not being set properly because conditionally closes the window if no active editor. !
There are context keys that are now loose, for example
Follow up work
Code change:
], { sticky: true, <del> neverShowAgain: { id: 'terminalConfigHelper/launchRecommendationsIgnore', scope: NeverShowAgainScope.WORKSPACE }, </del> <ins> neverShowAgain: { id: 'terminalConfigHelper/launchRecommendationsIgnore', scope: NeverShowAgainScope.GLOBAL }, </ins> onCancel: () => { /* __GDPR__ "terminalLaunchRecommendation:popup" : {

Related discussion:
text: Problem: A popup opens, displaying: "The 'Remote - WSL' extension is recommended for opening a terminal in WSL." It has a 'Dont Show Again' and an 'Install' option. Clicking Don't Show Again has no effect. Expected Behaviour: Once I click Don't Show Again, this popup doesn't appear every single time I open the WSL terminal in VS Code. VSCode Version: 1.38.1 (user setup) OS Version: Windows_NT x64 10.0. Steps to Reproduce: WSL Ubuntu installed on Windows. the WSL integrated terminal on VS Code. Does this issue occur when all extensions are disabled?: No.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.614 --- <!-- score: 0.559 --- <!-- score: 0.549 --- <!-- score: 0.54 --- <!-- score: 0.52 --<!-- potentialduplicatescomment --
I wanna take a shot at this!
Does this happen on different workspaces or on the same workspace? Edit: I have checked and this only happens when you open different workspaces (Different project folders with VSCode) I personally think that this should not be the case and should be global so I will make a pull request for it.
Sorry for the late reply. I see you've already pushed a fix for this, so thanks a lot :)
Should I close the issue now?
Code change:
} private refreshTitle(): void { <ins> if (this._disposed) { return; } </ins> if (this.contextService.getWorkbenchState() === WorkbenchState.WORKSPACE) { this.updateTitle(EmptyView.NAME); } else { this.updateTitle(this.title); } } <ins> override dispose(): void { this._disposed = true; super.dispose(); } </ins> }

Related discussion:
text: This is a valid bug. To repro: Open an empty window Open the explorer view. Make sure you have welcome page opened in the editor. Click on link the empty view Select a folder to open You will see above error trace in the console
No Folder Opened view () is removed when folder is opened. When removed this view is disposed. Following listener is getting invoked even after view is disposed It is because, view is being removed/disposed by listening to the same event It seems, once an event is fired all its listeners are invoked even if one of the listeners is disposed in the middle. This is causing the listener to be called even if it is disposed. Assigning to you also because it is related welcome view.
What link should I click? !
You have to make sure welcome page is opened <img width="955" alt="image" src="https://user-"
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
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!
/verified
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.
Code change:
if (!item.completion.command) { // done this.model.cancel(); <del> this.model.clear(); </del> } else if (item.completion.command.id === TriggerSuggestAction.id) { // retigger

Related discussion:
text: so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected