jiebi/CodeConvo huggingface dataset:
Code change:
if (options?.instanceToSplit && typeof shellLaunchConfig.cwd !== 'object' && typeof options.instanceToSplit.shellLaunchConfig.cwd === 'object') { shellLaunchConfig.cwd = URI.from({ scheme: options.instanceToSplit.shellLaunchConfig.cwd.scheme, <ins> authority: options.instanceToSplit.shellLaunchConfig.cwd.authority, </ins> path: shellLaunchConfig.cwd || options.instanceToSplit.shellLaunchConfig.cwd.path }); }

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. --Version: 1.58.0-insider (user setup) Commit: Date: 2021-07-01T09:30:57.217Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: error I think only occurs using Workspaces. A single project, the terminals seem to work fine. However, with multiple projects, the environment gets confused. Terminal (ctrl+shift+) Terminal I get this error message: 'The termial process failed to launch: Starting directory (cwd) "homeusernamemyproject"'. The first terminal works, but it's the second or subsequent terminal that creates the error. This is using the VSCode for Windows using WSL Remote. This error has now existed for at least a week in the Insiders edition. I am surprised this has not already been brought up. I think the error is indicating that its confusing a windows path for a linux path. Because this is using WSL-Remote, the path should be using forward slashes not backslashes for windows. This happens when "terminal.integrated.splitCwd" is inherited or initial. The workaround is to set this to workspaceRoot, then it works. However, it's annoying not to have inherited or initial working. Also, nowhere in my settings is "cwd" assigned anywhere.
Code change:
if (options?.instanceToSplit && typeof shellLaunchConfig.cwd !== 'object' && typeof options.instanceToSplit.shellLaunchConfig.cwd === 'object') { shellLaunchConfig.cwd = URI.from({ scheme: options.instanceToSplit.shellLaunchConfig.cwd.scheme, <ins> authority: options.instanceToSplit.shellLaunchConfig.cwd.authority, </ins> path: shellLaunchConfig.cwd || options.instanceToSplit.shellLaunchConfig.cwd.path }); }

Related discussion:
text: Also there is , but I suspect the issue on MacOS is different. Jae
The bottom line: Only while using Workspaces, the first or default terminal is properly run in WSL2. However, any subsequent new terminals are being recognized as a Windows environment, not Linux. Somehow the combination of Workspace+WSL is messing up the terminal environment.
I just discovered there is a command called "Create new Integrated terminal (In Active Workspace)"; where as the default "New Terminal" calls "Create new Integrated terminal". This is another possible workaround. However, you have to make sure the active file is where you want the new terminal to be created. You lose the ability to select which folder to create the new terminal in, unfortunately.
Can repro: ! multi-root workspace in WSL +shift+ +shift+5
Ah this is happening because we're getting a instead of a here:
I'm also getting this issue when using inherited for workspaces and remote ssh from a windows to a linux host. If I reload the window I am able to split the terminal for terminals that were created before the reload. Version: 1.58.2 (system setup) Commit: Date: 2021-07-14T22:10:15.214Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0.
Same here.
As a workaround for this issue in version 1.58, I was using this setting: But now in version 1.59.0, the issue happens with any values .
Awesome! Just got the fix in insiders! Thank you!
Verified fixed in
Code change:
// High Contrast Events ipc.on('vscode:enterHighContrast', (event) => { <del> this.partService.joinCreation().then(() => { this.themeService.setColorTheme(VS_HC_THEME, false); }); </del> <ins> const windowConfig = this.configurationService.getConfiguration<IWindowSettings>('window'); if (windowConfig && windowConfig.autoDetectHighContrast) { this.partService.joinCreation().then(() => { this.themeService.setColorTheme(VS_HC_THEME, false); }); } </ins> }); ipc.on('vscode:leaveHighContrast', (event) => { <del> this.partService.joinCreation().then(() => { this.themeService.setColorTheme(VS_DARK_THEME, false); }); </del> <ins> const windowConfig = this.configurationService.getConfiguration<IWindowSettings>('window'); if (windowConfig && windowConfig.autoDetectHighContrast) { this.partService.joinCreation().then(() => { this.themeService.setColorTheme(VS_DARK_THEME, false); }); } </ins> }); // Configuration changes

Related discussion:
text: VSCode Version: 1.8.0 OS Version: Windows Version 6.3.9600 (Windows 8.1 Enterprise) Steps to Reproduce: High Contrast on Windows VS Code, look at the glorious High Contrast theme a different theme, because you would rather work in that VS Code, your theme choice gets overridden. Essentially, I'd like to be able to disable the auto-detection of the High Contrast theme I'm using in Windows via some setting, because while I prefer Windows in High Contrast mode, I dislike looking at VS Code's High Contrast theme.
I wholeheartedly agree. I'm okay with the default being auto-detection, for the accessibility scenario, but it should definitely be possible to disable this functionality via settings.
An option makes sense to me. If someone wants to provide a PR
Done,
Could you please re-open this issue? Unfortunately, my PR only affected the high-contrast swap that occurred when changing Windows theme while VSCode is open, not the initial theme that is set when VSCode starts, or opens a new folder. I have a new PR that completes the fix.
[x] To verify (Windows): Normally VS Code switches to HC mode automatically when windows is running in HC mode. Verify this new setting can be used to prevent this automatic switch from happening (both on startup as well as when Code is running and you change HC mode in Windows).
Code change:
/** Ellipsis on hover **/ <del> .monaco-editor .suggest-widget:not(.docs-side) .monaco-list .monaco-list-row:hover>.contents>.main>.right.can-expand-details>.details-label { </del> <ins> .monaco-editor .suggest-widget:not(.docs-side) .monaco-list .monaco-list-row.focused:hover>.contents>.main>.right.can-expand-details>.details-label { </ins> width: calc(100% - 26px); }

Related discussion:
text: VS Code Version: code-oss-dev(1.64.0) OS Version: win10 Steps to Reproduce: vscode web file "w", and click readmore icon at warn suggest label, but show webkitURL details in right panel !
Code change:
await p2; }); <ins> test('Ranges where additionalTextEdits are applied are not appropriate when characters are typed #177591', async function () { disposables.add(languageFeaturesService.completionProvider.register({ scheme: 'test-ctrl' }, { _debugDisplayName: 'test', provideCompletionItems(doc, pos) { return { suggestions: [{ kind: CompletionItemKind.Snippet, label: 'aaa', insertText: 'aaa', range: Range.fromPositions(pos), additionalTextEdits: [{ range: Range.fromPositions(pos.delta(0, 10)), text: 'aaa' }] }] }; } })); { // PART1 - no typing editor.setValue(`123456789123456789`); editor.setSelection(new Selection(1, 1, 1, 1)); const p1 = Event.toPromise(controller.model.onDidSuggest); controller.triggerSuggest(); const e = await p1; assert.strictEqual(e.completionModel.items.length, 1); assert.strictEqual(e.completionModel.items[0].textLabel, 'aaa'); controller.acceptSelectedSuggestion(false, false); assert.strictEqual(editor.getValue(), 'aaa1234567891aaa23456789'); } { // PART2 - typing editor.setValue(`123456789123456789`); editor.setSelection(new Selection(1, 1, 1, 1)); const p1 = Event.toPromise(controller.model.onDidSuggest); controller.triggerSuggest(); const e = await p1; assert.strictEqual(e.completionModel.items.length, 1); assert.strictEqual(e.completionModel.items[0].textLabel, 'aaa'); editor.trigger('keyboard', 'type', { text: 'aa' }); controller.acceptSelectedSuggestion(false, false); assert.strictEqual(editor.getValue(), 'aaa1234567891aaa23456789'); } }); </ins> });

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes Version: 1.77.0-insider (Universal) Commit: Date: 2023-03-17T21:00:47.582Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin arm64 20.6.0 Sandboxed: Yes Steps to Reproduce: Execute the following extension example: a text file and select a completion item , type , and select a completion item results are different https://user-
This is specific to additional edits that are after and on the same line as the suggestion. The newly typed characters (type after return the list of item and before selecting one) aren't taken into account
Code change:
} # Debug trapping/preexec inspired by starship (ISC) <del> __vsc_dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d ')" if [[ -z "$__vsc_dbg_trap" ]]; then </del> <ins> if [[ -n "${bash_preexec_imported:-}" ]]; then </ins> __vsc_preexec_only() { __vsc_status="$?" __vsc_preexec } <del> trap '__vsc_preexec_only "$_"' DEBUG elif [[ "$__vsc_dbg_trap" != '__vsc_preexec "$_"' && "$__vsc_dbg_trap" != '__vsc_preexec_all "$_"' ]]; then __vsc_preexec_all() { __vsc_status="$?" builtin eval ${__vsc_dbg_trap} __vsc_preexec } trap '__vsc_preexec_all "$_"' DEBUG </del> <ins> precmd_functions+=(__vsc_prompt_cmd) preexec_functions+=(__vsc_preexec_only) else __vsc_dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d ')" if [[ -z "$__vsc_dbg_trap" ]]; then __vsc_preexec_only() { __vsc_status="$?" __vsc_preexec } trap '__vsc_preexec_only "$_"' DEBUG elif [[ "$__vsc_dbg_trap" != '__vsc_preexec "$_"' && "$__vsc_dbg_trap" != '__vsc_preexec_all "$_"' ]]; then __vsc_preexec_all() { __vsc_status="$?" builtin eval ${__vsc_dbg_trap} __vsc_preexec } trap '__vsc_preexec_all "$_"' DEBUG fi </ins> fi __vsc_update_prompt

Related discussion:
text: With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?
Code change:
} }); <del> const task = this._activeSession.provider.provideResponse(this._activeSession.session, request, progress, requestCts.token); </del> <ins> const task = this._activeSession.provider.provideResponse(this._activeSession.session, request, progress, this._activeRequestCts.token); </ins> let response: ReplyResponse | ErrorResponse | EmptyResponse; try {

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.
Code change:
import { IViewContainersRegistry, ViewContainerLocation, Extensions as ViewContainerExtensions, IViewsService } from 'vs/workbench/common/views'; import { IClipboardService } from 'vs/platform/clipboard/common/clipboardService'; import { IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; <del> import { ContextKeyExpr, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; </del> <ins> import { ContextKeyDefinedExpr, ContextKeyExpr, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; </ins> import { IQuickAccessRegistry, Extensions } from 'vs/platform/quickinput/common/quickAccess'; import { InstallExtensionQuickAccessProvider, ManageExtensionsQuickAccessProvider } from 'vs/workbench/contrib/extensions/browser/extensionsQuickAccess'; import { ExtensionRecommendationsService } from 'vs/workbench/contrib/extensions/browser/extensionRecommendationsService';

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I saw and created this issue anyway because I think that issue is a) too old b) has too many other things going on. <!-- Describe the feature you'd like. --For me, personally, I'd like a simple way to enable/disable automatic extension updates per extension. I really care about updates for many of them and want to read the changelog before I update but for some, like Copilot, who get several updates a day, I really just want to always be on the latest. Copying section 7 from the above: Users could opt-out of Auto-Update for specific extensions, with toggle button next to Disable/Uninstall in Extensions Sidebar (under gear icon menu) and next to those buttons in Extensions Detail Page. This could allow users to stick with previous versions before new high-risk permissions became required This could allow avoiding updating to problematic versions of extensions until issues are resolved. This could allow users to manually review/approve updates based on reviews and changelog for higher (security or reliability) risk extensions This could be controlled per extension without disabling globally as may be desired by default for most extensions. Can be set per extension to "Default" vs Auto-Update vs. Disable Automates, like with Firefox, with Default behavior controlled through global setting. Could provide Undo Update button or choose from version history (like with Chrome/Firefox extension stores) on extension details page, to enable rollback to previous version after an update causes issues, instead of just disabling until if/when ever fixed.
Have you tried to select specific version for extension? This should effectively force version and prevent updates.
No, would that still show if there was an update available?
It should show. Also September 22 update had few updates to including . Check it out
Supported auto updating options per extension/publisher <img width="550" alt="image" src=""This is enabled when auto update mode is disabled or set to (new config)
Code change:
import { Handler } from 'vs/editor/common/editorCommon'; import { ITextModel } from 'vs/editor/common/model'; import { ViewModel } from 'vs/editor/common/viewModel/viewModelImpl'; <del> import { DeleteAllLeftAction, DeleteAllRightAction, DeleteDuplicateLinesAction, DeleteLinesAction, IndentLinesAction, InsertLineAfterAction, InsertLineBeforeAction, JoinLinesAction, KebabCaseAction, LowerCaseAction, SnakeCaseAction, SortLinesAscendingAction, SortLinesDescendingAction, TitleCaseAction, TransposeAction, UpperCaseAction } from 'vs/editor/contrib/linesOperations/browser/linesOperations'; </del> <ins> import { CamelCaseAction, DeleteAllLeftAction, DeleteAllRightAction, DeleteDuplicateLinesAction, DeleteLinesAction, IndentLinesAction, InsertLineAfterAction, InsertLineBeforeAction, JoinLinesAction, KebabCaseAction, LowerCaseAction, SnakeCaseAction, SortLinesAscendingAction, SortLinesDescendingAction, TitleCaseAction, TransposeAction, UpperCaseAction } from 'vs/editor/contrib/linesOperations/browser/linesOperations'; </ins> import { withTestCodeEditor } from 'vs/editor/test/browser/testCodeEditor'; import { createTextModel } from 'vs/editor/test/common/testTextModel';

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --There is Title Case, Snake Case, Lowercase, Uppercase, but no Camel Case. It would be nice to transform: -
It would be a great feature. You could use that extension: until then. I also think that they should work on the to exclude articles and even custom words. instead of which is not accaptable in many academic organizations.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -a7ce-58b9-b1f9- --This feature request has not yet received the 20 community it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
Up for a PR anyone?
I to do this. I have more details in the PR description about how different use cases should be handled. I don't really have a strong opinion on it. I wrote a personal extension long ago that has it's own set of rules, so I probably will keep using that over the one I implemented in the PR.
Code change:
if (docUri.scheme === Schemes.untitled) { return vscode.workspace.workspaceFolders?.[0]?.uri; } <del> return docUri; </del> <ins> return Utils.dirname(docUri); </ins> } async function insertLink(activeEditor: vscode.TextEditor, selectedFiles: vscode.Uri[], insertAsImage: boolean): Promise<void> {

Related discussion:
text: Testing Using the simple file dialog this is a bit inconvenient: <img width="567" alt="image" src="https://user-"
(Also on Linux which I'm supposed to test.)
Code change:
"workspaceTrust", "telemetry", "windowActivity", <del> "interactiveUserActions" </del> <ins> "interactiveUserActions", "envCollectionWorkspace", "envCollectionOptions" </ins> ], "private": true, "activationEvents": [],

Related discussion:
text: It's used in , this would be easiest after that's merged.
I wish instead of explicitly checking whether proposed API is enabled in in the implementation, we could check it when checking distro for whether an extension is allowed a proposal instead.
the list of allowed extensions is not available in code - oss though on local or in CI
That's fair but do we really need to check in code - oss when developing? I would think is being tested out in the final build that's published.
not my area but being strict is good for proposals and it's good to align oss with the product in areas like this. Consider a fork of VS Code that does not have the check, extensions could use the proposals without warning which could lead to easy breakages.
Code change:
resolved "https://registry.yarnpkg.com/jschardet/-/jschardet-3.0.0.tgz#898d2332e45ebabbdb6bf2feece9feea9a99e882" integrity sha512-lJH6tJ77V8Nzd5QWRkFYCLc13a3vADkh3r/Fi8HupZGWk2OVVDfnZP8V/VgQgZ+lzW0kG2UGb5hFgt3V3ndotQ== <ins> jsonfile@^6.0.1: version "6.1.0" resolved "https://registry.yarnpkg.com/jsonfile/-/jsonfile-6.1.0.tgz#bc55b2634793c679ec6403094eb13698a6ec0aae" integrity sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ== dependencies: universalify "^2.0.0" optionalDependencies: graceful-fs "^4.1.6" </ins> kerberos@^2.0.1: version "2.0.1" resolved "https://registry.yarnpkg.com/kerberos/-/kerberos-2.0.1.tgz#663b0b46883b4da84495f60f2e9e399a43a33ef5"

Related discussion:
text: a folder in WSL and show logs the error log !
Are things broken in this case or just a bad stack trace. I'll take a look to see if I missed a module include somewhere
Just a bad stacktrace from what I see, though I didn't intentionally go test things thoroughly
Code change:
} .monaco-hover .markdown-hover > .hover-contents:not(.code-hover-contents) { <del> max-width: 500px; </del> word-wrap: break-word; }

Related discussion:
text: When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route.