jiebi/CodeConvo huggingface dataset:
Code change:
const title = localize('import profile preview', "Import"); if (!userDataProfileImportState.isEmpty()) { <del> let importProfile = await this.selectProfileResources( userDataProfileImportState, localize('import title', "{0}: {1} ({2})", PROFILES_CATEGORY.value, title, profileTemplate.name), localize('import description', "Choose what to import") ); if (importProfile === undefined) { return; } if (!importProfile) { importProfile = await this.showProfilePreviewView(`workbench.views.profiles.import.preview`, title, title, localize('cancel', "Cancel"), userDataProfileImportState); } </del> <ins> const importProfile = await this.showProfilePreviewView(`workbench.views.profiles.import.preview`, title, title, localize('cancel', "Cancel"), userDataProfileImportState); </ins> if (!importProfile) { return; }

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: MacOS Big Sur latest Steps to Reproduce: Create a new profile Click on the Profile Activity Bar icon, then choose Result: the quick pick comes up... ! Now click on the menu item to bring up the view Click on the menu item again Result: focus just moves to the pane ! Expectation: Show the Quick Pick so the menu works the same regardless of whether or not the content view is open
I was also hit by this - that by clicking on "Export Profile..." it looks like it has no effect, when it fact it just passed the focus. we could always show quick pick as Chris suggests?
What about the contents view when you click on again? Does this has to be closed or remain like this? May I understand what is confusing in navigating to the contents view when you click on export profile button?
I think you can leave the view open, but I would open the Quick Pick right away, not force the user to click on the Export button (again).
Another idea (that was also mentioned in the UX call) is how about always open the view and ditch quick pick? This was initial flow actually.
I think that flow might work. My biggest concern is that users might not notice that the focus moved to the view (especially if the view is already open). Long term - maybe the view becomes a custom editor? fyi
Quick pick is removed and by default we show the contents view now.
Code change:
'remote'?: string; 'force'?: boolean; 'do-not-sync'?: boolean; <ins> 'preserve-env'?: boolean; </ins> 'force-user-env'?: boolean; 'force-disable-user-env'?: boolean; 'sync'?: 'on' | 'off';

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.82.3 OS Version: Ventura 13.6 This one was tricky to investigate and is impacting the and & scenario. In that scenario, VS Code is started from one application using the macOS command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue. When opening either from the macOS Finder or through , the VS Code application will expand the PATH of its subprocess so that extensions that depend on something in the path of the terminal will find it. So in my case, if I start VS Code from the Finder, the processes will look like this: This is expected and good. Extensions can find in the PATH. The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get: So in my second workspace, will not be found in the PATH.
Code change:
'remote'?: string; 'force'?: boolean; 'do-not-sync'?: boolean; <ins> 'preserve-env'?: boolean; </ins> 'force-user-env'?: boolean; 'force-disable-user-env'?: boolean; 'sync'?: 'on' | 'off';

Related discussion:
text: For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal) Steps to Reproduce: Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI) the Sandbox for the project: <img width="562" alt="Screenshot 2023-10-03 at 10 33 02 AM" src=""the look like this: the variables and to point to 2 different workspaces. the project, I personally use in command line. all VS Code instances. the .app from the Finder, it will be in if you built from the command line by default. the button As you can see from the code, the .app will: set the PATH with a marker open a new VS Code workspace on workspace1 wait a bit open a new VS Code workspace on workspace2 activity monitor, find the child process ID: <img width="1045" alt="Screenshot 2023-10-03 at 10 40 50 AM" src=""the terminal, look at their path: (Your pid may vary) that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:
I think you're best equip to handle this issue? but feel free to reassign to whoever.
I can't repro this. To know more, please do the following: Quit VS Code From a Terminal, run , this should open VS Code In that window, run and set it to . Then, from a Terminal, run , this should open the second window On the second window, reveal the Output panel and the Window logs. Search for , what do you find?
the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS. As I said in the bug:
Using is the same as launching from Finder. Let me know the result.
Code change:
'remote'?: string; 'force'?: boolean; 'do-not-sync'?: boolean; <ins> 'preserve-env'?: boolean; </ins> 'force-user-env'?: boolean; 'force-disable-user-env'?: boolean; 'sync'?: 'on' | 'off';

Related discussion:
text: I'm afraid it's not exactly the same as it exhibits a different behavior as it appears the second instance of the process will simply inherit the PATH of the process that started it, instead of expanding the PATH to be like a terminal Using twice will work as expected from the Terminal as the second instance of the process will inherit the PATH of the Terminal. Using the repro steps to create an app that will call on Visual Studio Code twice won't work as expected. If I close all VSC instances, and do twice on two different workspaces, I get: Things are visibility different as the main Code process seems to inherits the PATH from the Terminal. Whereas if I launch Code manually from the Finder, I get: So there is a difference.
Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), did not propagate environments. It seems like it does now. Can you try just once more with: , replacing with the path to the workspace? Thanks, I really appreciate it!
Version: 1.84.0-insider Commit: With from the Terminal I get the same behavior as :
Hi we're seeing a growing number of customer reports on this. I think I've provided all the info that was needed including a way to create a self-contained repro. How could we get this looked at? Thanks!
Same here guys. Just installed unity + vscode and have this message about missing net sdk. I came from here.
I came here from microsoft/vscode-dotnettools as well – and I'm glad I did! I've been banging my head against the " isn't on the PATH" issue (and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code. I generally open my Unity Projects is with the following: the project in Unity. "Open C# Project" from the Assets menu. <img width="253" alt="image" src=""If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find !" issues. a new VS Code window (keyboard shortcut/menu/palette/whatever).
Code change:
'remote'?: string; 'force'?: boolean; 'do-not-sync'?: boolean; <ins> 'preserve-env'?: boolean; </ins> 'force-user-env'?: boolean; 'force-disable-user-env'?: boolean; 'sync'?: 'on' | 'off';

Related discussion:
text: the project from within VS Code. In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there. Regardless, if I open the project in VS Code in this manner, everything works as expected.
sorry for the silence here. Let's try to figure this one out. First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why... In any case, can I ask you for one more piece of info? from Finder (main process regular PATH, Code Helper with sourced PATH) a Terminal, call the command with the path to the second workspace. What's the of that second Code Helper process that comes up? Resolved?
Hey thanks for bumping this, happy new year, looking forward to having a resolution for this. That happened to me before I turned the sandbox off. See step 2 of the repro? We could also try the real world scenario with Unity, but it's going to be a slightly longer setup, I'd encourage you to reach out to my email at work to help get you setup. In that case: The main Visual Studio App inherits the PATH of the Finder (so just /usr/bin:/bin) The first process gets a PATH expended. The second process inherits the PATH of the Terminal, verified by doing: Just before calling in the Terminal.
Sorry about that. It runs correctly now! And I can repro! Funny: it seems to only affect the variable. If, say, one adds to , that gets properly propagated to both extension hosts (). Interesting, digging more...
Nice! Good luck :)
Got it!
<!-- 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!
/verified
Code change:
// 	}); // }); <del> test('No expanding when html is excluded in the settings in completion list', async () => { </del> <ins> test.skip('No expanding when html is excluded in the settings in completion list', async () => { </ins> const oldConfig = workspace.getConfiguration('emmet').inspect('excludeLanguages')?.globalValue; await workspace.getConfiguration('emmet').update('excludeLanguages', ['html'], ConfigurationTarget.Global); await testHtmlCompletionProvider(new Selection(9, 6, 9, 6), '', '', true);

Related discussion:
text: Build:
Hit this again with
Again:
is trying to get more details when this happens:
Also saw this
This is because of atomic writing and in windows renaming is failing sometimes and I think this is because some other processes (defender ) might be holding the file that has to be renamed. I have seen similar issues in extensions when I implemented atomic installation of extensions long time back, ie. extracting the zip to a temp file in the same folder and renaming it. I have to retry renaming multiple times to avoid this. I am not sure if this is the right solution for FS atomic write. So, I would wait for until then I will revert my atomic write changes.
Check this issue - This is common in windows and it seems the workaround is to retry.
should the skipped tests be restored, I think they are still skipped
Seems like they can probably be restored.
Code change:
// to get better profile traces. Last, we listen on stdout for a signal that tells us to // stop profiling. if (args['prof-startup']) { const portMain = await findFreePort(9222, 10, 6000); const portRenderer = await findFreePort(portMain + 1, 10, 6000); const portExthost = await findFreePort(portRenderer + 1, 10, 6000);

Related discussion:
text: This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).
Code change:
// to get better profile traces. Last, we listen on stdout for a signal that tells us to // stop profiling. if (args['prof-startup']) { const portMain = await findFreePort(9222, 10, 6000); const portRenderer = await findFreePort(portMain + 1, 10, 6000); const portExthost = await findFreePort(portRenderer + 1, 10, 6000);

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 agent has a refer command, massage the input to include the agent name await this._instaService.invokeFunction(sendRequest, massagedInput); <del> if (!this._session.lastExchange) { // DONE when there wasn't any exchange yet. We used the inline chat only as trampoline return State.ACCEPT; } return State.WAIT_FOR_INPUT; </del> <ins> return State.ACCEPT; </ins> } this._session.addInput(new SessionPrompt(input, this._nextAttempt, this._nextWithIntentDetection));

Related discussion:
text: Just asked hi: ! Expected: ! Version: 1.88.0-insider (user setup) Commit: Date: 2024-03-25T05:49:32.344Z Electron: 28.2.6 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. GitHub Copilot Chat v0.14. (pre-release)
because of
To verify configure have a very wide view port ask AI to change some code make sure the input widget is full width of the zone widget
Code change:
// if agent has a refer command, massage the input to include the agent name await this._instaService.invokeFunction(sendRequest, massagedInput); <del> if (!this._session.lastExchange) { // DONE when there wasn't any exchange yet. We used the inline chat only as trampoline return State.ACCEPT; } return State.WAIT_FOR_INPUT; </del> <ins> return State.ACCEPT; </ins> } this._session.addInput(new SessionPrompt(input, this._nextAttempt, this._nextWithIntentDetection));

Related discussion:
text: cmd+i now cmd+backspace invokes instead of deleting the line in the text editor The ChatWidget is writing its context keys to the editor's ContextKeyService, so we need a scoped CKS at some point, either inside the ChatWidget or outside in the inline widgets
pushing a fix to use a scoped CKS but this does look like debt. Isn't a better fix to reset context keys when hiding/dispose the chat widget?
I don't think those context keys should be applied on the editor at all, they are intended to just be active inside the widget's dom tree.
Code change:
white-space: nowrap; } <ins> .monaco-select-box-dropdown-container > .select-box-dropdown-list-container .monaco-list .monaco-list-row > .option-text-description { display: none; } </ins> .monaco-select-box-dropdown-container > .select-box-dropdown-container-width-control { flex: 1 1 auto; align-self: flex-start;

Related discussion:
text: New enum/select box detailed descriptions should be read by reader. Add describedby attribute handling for details provider within selectbox.
Either describedby or just
Yep, I've thought about live/alert also. By my research this does not really match the expected taxonomy for the accessibility tree, an extended description is pretty much exactly what describedby is for. That said, describedby probably will not be happy changing which will mean I will need the static set of descriptions in the Dom. Not a big deal, just another example of where nothing is straightforward. But, that's why we get paid the big bucks ... well at least you :-o ! What I really want to solve is getting rid of the multiple 'clickable' readings. I think I may have a way to avoid that which will be very important for these descriptions given the number of links.
Good point, I have no idea if pointing all of the selectbox items at the same details box will work, or if there's something we can do to order events to make it work better. Or maybe changing the 'id' of the details element for each item. I'm very curious what's causing that! Very weird.
describedby can have a list of IDs associated with it. like labeled by and most other ARIA aspects it does not like things changing underneath it, that of course is what aria-live is for but, but everything I read says use this judiciously. I think having a separate set of descriptions (modified for reader output/minimal clickable) will not be a big deal. Just as the options are static, so are the descriptions so hiding them in the select for use will not be an issue. I haven't done the definitive experiment yet but, I believe the multiple clickable issue has to do with something like this: I think the reader can find these as all clickable elements when they are descendents of a managed accessibility tree. my research has yet to determine if this is considered a bug or as designed
Code change:
"editor.foreground": "#000000e4", "editor.inactiveSelectionBackground": "#E5EBF1", "editor.selectionHighlightBackground": "#ADD6FF80", <del> "editorCursor.foreground": "#005FB8", </del> "editorGroup.border": "#0000001a", "editorGroupHeader.tabsBackground": "#f8f8f8", "editorGroupHeader.tabsBorder": "#0000001a",

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.75.0-insider OS Version: Linux Hello, IMHO, the block cursor could use a different background. Default Dark+ Experimental (v2): ! ! Default Dark+: ! ! Default Dark+ Experimental (v2): with some cursor background color. For ex: ! ! ! ! Edit (one more option) (with color set to 's value, giving inverted cursor effect) ! ! Thanks
Code change:
} @throttle <ins> async pullFromRemote(remote : string, branch : string): Promise<void> { await this.run(Operation.Pull, () => this.repository.pull(false, remote, branch)); } @throttle </ins> async push(): Promise<void> { await this.run(Operation.Push, () => this.repository.push()); }

Related discussion:
text: In VS Code we able to push git repos to different places with "git push to" and choosing the remote server to push. I'll be nice if we can be able to choose from the repo to pull files, and manage the default remote, today the first remote repo is the default isn't possible to change that via VS Code
Thanks for all your contributions. You all created a PR to solve the same issue; all in a surprisingly similar way. I wanted to keep the record of all your work so I did an octopus merge with git, thus keeping your names in history. Thanks once again!