jiebi/CodeConvo huggingface dataset:
Change:
let mut keyring_storage = ThreadKeyringStorage::default(); let mut file_storage = FileStorage(PersistedState::new(self.file_storage_path.clone())); <del> let keyring_storage_result = match std::env::var("VSCODE_CLI_USE_FILE_KEYCHAIN") { Ok(_) => Err(wrap("", "user prefers file storage").into()), _ => keyring_storage.read(), </del> <ins> let native_storage_result = if std::env::var("VSCODE_CLI_USE_FILE_KEYCHAIN").is_ok() || self.file_storage_path.exists() { Err(wrap("", "user prefers file storage").into()) } else { keyring_storage.read() </ins> }; <del> let mut storage = match keyring_storage_result { </del> <ins> let mut storage = match native_storage_result { </ins> Ok(v) => StorageWithLastRead { last_read: Cell::new(Ok(v)), <ins> fallback_storage: Some(file_storage), </ins> storage: Box::new(keyring_storage), }, Err(e) => {

Discussion:
<!-- 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?: Not sure. I run "code tunnel" without opening the UI. <!-- 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.80.0 OS Version: Ubuntu 22.04 LTS Steps to Reproduce: Install VSCode or Code Cli on Ubuntu Desktop 22.04 "code tunnel" on Ubuntu. server license terms and login to and enter the code. tunnel will show: . VSCode tunnel and rerun "code tunnel". It will ask for GitHub authentication again, because it failed to update keyring.
Seems to duplicate the upstream issue on To work around this, you can set the environment variable (e.g. by running and reconnecting). But this seems fairly common, we should automatically use a file keychain if we get this error.
Hi Connor, Thanks for your help! It would be wonderful if the error can be automatically dealt with since many people don't know the environment variable.
yes,
<!-- 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!
Putting in a new line in does the trick for me. (putting the env var in a global file ensures that it will be defined regardless of where it's running or who is running it; note that on some systems this may be a massive security hole)
I now see this in insiders: and then when I restart: looks verified to me.
Change:
const scrollbarHeight = 5; <ins> class TerminalOutputProvider implements ITextModelContentProvider { static scheme = 'TERMINAL_OUTPUT'; constructor( @ITextModelService textModelResolverService: ITextModelService, @IModelService private readonly _modelService: IModelService ) { textModelResolverService.registerTextModelContentProvider(TerminalOutputProvider.scheme, this); } async provideTextContent(resource: URI): Promise<ITextModel | null> { const existing = this._modelService.getModel(resource); if (existing && !existing.isDisposed()) { return existing; } return this._modelService.createModel(resource.fragment, null, resource, false); } } </ins> export class TerminalInstance extends Disposable implements ITerminalInstance { private static _lastKnownCanvasDimensions: ICanvasDimensions | undefined; private static _lastKnownGridDimensions: IGridDimensions | undefined;

Discussion:
Testing I feel like I would mostly open output as a "one-off" editor to inspect test failures, for example. Having the prompt whenever I want to close the editor, since it's marked as untitled, is annoying. Instead, should it be opened as an ordinary read-only file which allows the user to if they want to keep it?
do you know how to do this in core? I also want to know how to do it in extensions for a similar problem in luna paint.
You can register an , I do that for test output: Alternatively (and in extensions) you can register a readonly FileSystemProvider.
Thanks, I'm a little surprised there's no option for extensions in as it seems like a common thing people would want to do.
Change:
this.unstickyEditorTabsControl.openEditor(editor); } <del> this.handlePinnedTabsLayoutChange(); </del> <ins> this.handleTabBarsStateChange(); </ins> } else { if (this.model.isSticky(editor)) {

Discussion:
Type: <bBug</bfile A from EXPLORER tab with file A file B from EXPLORER -breadcrumb shows file B path (correct) on the pinned tab with file A -breadcrumb shows file B path but should file A This is the minimal case. When I have multiple pinned tabs and open other files, the breadcrump gets more random. UPDATE: Looks like the bug only comes out if this setting is set to true: VS Code version: Code 1.92.2 (, 2024-08-14T17:29:30.058Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.153.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ macos-modern-theme2.3.19 better-cpp-syntax1.27.1 remote-containers0.380.0 remote-ssh0.113.1 remote-ssh-edit0.86.0 remote-wsl0.88.2 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.2 vscode-clangd0.1.29 regionfolder1.0.22 cmake-tools1.18.44 cpptools1.21.6 workspace-include-what-you-use0.0.3 cmake0.0.17 (4 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This doesn't reproduce for me. Please try without extensions enabled and without custom settings
I turned off extensions and custom settings. I nailed it down to this setting in It appears that the bug is reproducible only if is true.
can you help here? It seems that pinned, extra-row items don't make the call to the breadcrumbs controls, like how it is done for instance for the
Thanks for steps. could you take a look?
Thanks for reporting. When switching to the last previous active tab of the other tab bar it wasn't updating the breadcrumbs. Made a fix
<!-- 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!
Still doesn't work correctly on current insiders version. Version: 1.93.0-insider (user setup) Commit: Date: 2024-08-23T06:45:56.108Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.
Change:
import { FileKind } from 'vs/platform/files/common/files'; import { compareFileNames, comparePaths } from 'vs/base/common/comparers'; import { FuzzyScore, createMatches, IMatch } from 'vs/base/common/filters'; <del> import { IViewDescriptorService, ViewContainerLocation } from 'vs/workbench/common/views'; </del> <ins> import { IViewDescriptorService } from 'vs/workbench/common/views'; </ins> import { localize } from 'vs/nls'; import { IStorageService, StorageScope, StorageTarget } from 'vs/platform/storage/common/storage'; import { EditorResourceAccessor, SideBySideEditor } from 'vs/workbench/common/editor'; <del> import { SIDE_BAR_BACKGROUND, PANEL_BACKGROUND } from 'vs/workbench/common/theme'; </del> import { CodeEditorWidget, ICodeEditorWidgetOptions } from 'vs/editor/browser/widget/codeEditor/codeEditorWidget'; import { IEditorConstructionOptions } from 'vs/editor/browser/config/editorConfiguration'; import { getSimpleEditorOptions } from 'vs/workbench/contrib/codeEditor/browser/simpleEditorOptions';

Discussion:
Sometimes the tree sticky show shadow does not show. Make sure they use the proper overrides and that there is a default color if none is provided
are there any validation steps here?
verified- the scm sticky scroll showed on insiders, but not stable.
Change:
border-left: 3px solid rgba(0, 0, 0, 0.40); } <ins> .vscode-light.showEditorSelection .code-line .code-line:hover:before { border-left: none; } </ins> .vscode-dark.showEditorSelection .code-active-line:before { border-left: 3px solid rgba(255, 255, 255, 0.4); }

Discussion:
! Note the extra bar the right of the blue block quote bar
I hope my fix will work for you. :smile:
Change:
https-proxy-agent "^2.2.4" vscode-nls "^4.1.2" <del> vscode-json-languageservice@^4.1.2: version "4.1.2" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-4.1.2.tgz#c3873f791e23488a8b373e02c85c232bd625e27a" integrity sha512-atAz6m4UZCslB7yk03Qb3/MKn1E5l07063syAEUfKRcVKTVN3t1+/KDlGu1nVCRUFAgz5+18gKidQvO4PVPLdg== </del> <ins> vscode-json-languageservice@^4.1.3: version "4.1.3" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-4.1.3.tgz#851564e529e649c13b844f10a80ea1d9095591a9" integrity sha512-m/wUEt4zgCNUcvGmPr1ELo+ROQNKBgASpdOOAEpcSMwYE/6GzULZ1KfBhbX9or7qnC4E0oX+wwW+lrN3EUWCgw== </ins> dependencies: jsonc-parser "^3.0.0" minimatch "^3.0.4"

Discussion:
<!-- 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. --- Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-27T06:15:26.914Z Electron: 12.0.4 Chrome: 89.0.4389.114 14.16.0 V8: 8.9.255.24-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: Here is the error message ! The text version: <!-- 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. --
I'm seeing this too. I worked around it for now by creating with as the content. Interestingly, I still get schema completion in files so I guess this (built-in) extension is not even meant to be providing that? <details</details
I guess this was fixed by
Change:
this.cancelAllRequests(); await this.raw.disconnect(restart); <ins> if (!restart) { this._options.compoundRoot?.sessionStopped(); } </ins> } /**

Discussion:
Ever since I started using the new JS debugger, when running our top level target and then manually closing the code-oss window, the and targets remain: ! Eventually, maybe 1 minute later, the goes away, but the other one stays, I always have to manually disconnect from it. ! cc
This is because is set for the shared process and extension host, which allows them to reconnect when vscode is reloaded. Eventually js-debug in extension host gives up, but the shared process is using the previous Node debugger which doesn't give up. Both these are working as designed, this is kind of a downside of the compound launch configs in that there's no "compound stop".
Yeah, would actually LOVE a compound stop. Could this be a feature of compounds, & Meaning, if something like was set in the compound, all targets would share the same action, and I would see no actions.
We could add a attribute to the compound, however how would that work? Clicking stop on any of the compound sessions would send stop to all sessions? And it would never be rendered as dicsonnect?
Maybe compound launch configs could have a pseudo-root, which has a "stop" action that affects all individual configs? ` The compound config could have an option whether sessions can be stopped individually, or whether stopping one session is treated as stopping the whole set of configuration.
ok makes somewhat sense, the flaw of my proposel is that once compound starts 4 sessions those sessions are not related in any way. So adding a pseudo root might be smart. The pseudo root would not be rendered, and the pseudo root would remember the attribute. Here are code pointers for a PR. We should add the attribute and to the schema . Code pointer for the debug session to add the pseudo root stopAll smartness
I like both options.
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!
Please let's have the bot not do this for ourselves.
BTW, the bot's wording sounds wrong: in to the latest...
Much better, and I this attribute to our compound config. But the behavior partly confuses me and I opened
Change:
import { SelectionClipboardContributionID } from 'vs/workbench/contrib/codeEditor/browser/selectionClipboard'; import { getSimpleEditorOptions } from 'vs/workbench/contrib/codeEditor/browser/simpleEditorOptions'; <del> const enum DIMENSION_DEFAULT { WIDTH = 800 </del> <ins> const enum DEFAULT { WIDTH = 800, TOP = 25 </ins> } export interface IAccessibleContentProvider {

Discussion:
Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.

But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:
Change:
private _responsePendingAudioCue: IDisposable | undefined; private _hasReceivedRequest: boolean = false; private _runOnceScheduler: RunOnceScheduler; <ins> private _lastResponse: string | undefined; </ins> constructor(@IAudioCueService private readonly _audioCueService: IAudioCueService) { super();

Discussion:
all chat audio cues enabled, run something in the inline chat that takes more than 4 seconds to come back that the chat response received cue doesn't play - in the console, there's an error about how a user gesture is required. this is expected to a different tab, leaving the chat widget still open to the tab with the chat widget visible hear the chat response received cue going between tabs and notice the cue gets played every time
so this happens even when it doesn't take that long !
this is because is called when the editor tab changes
that happens here !
looks like we need to move this to before is deleted so we can call it like
I have a different approach that will work. Ideally we would fix this at the root - so pls feel free to do so as you're more familiar with the state code.
This still repros for me with the steps from
So switching tabs plays an audio cue for you ?
This does not repro for me with the steps in this issue or the steps in the other one
Change:
return; } <ins> historyService.replaceLast(notebookDocument.uri, value); </ins> historyService.addToHistory(notebookDocument.uri, ''); textModel.setValue('');

Discussion:
<!-- 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. --four cells from the interactive window input box, e.g. , , , reexecute multiple commands from earlier in your history, e.g. and use via the up arrow executing an entry from earlier in the history e.g. , scroll position resets to the bottom of the history, and you have to start over and scroll up from the most recent command (4 -3 - 2 -1). This can be frustrating for users who are trying to reexecute multiple commands. Note also that the original interactive window used to preserve your scroll history in the interactive window so that you didn't have to scroll back up through the entire history, and users have complained about this behavior change:
The expectation is that the interactive window input behaves just like a REPL. would address this. Per discussion with we should have shared logic for handing history traversal.
Any news on that? I agree with the PR that the current behavior is quite frustrating and deserves further attention.
Yes this is one of my main frustrations with the IW still. At minimum I just want the up arrow to go to the last executed code, not have cycle through like 20 cells every time I need to re-run something. And it did used to work this way ~1.5 yrs ago.
Change:
}; // A single default glob task was returned, just run it directly <del> if (taskGroupTasks.length === 1) { return resolveTaskAndRun(taskGroupTasks[0]); </del> <ins> if (groupTasks.length === 1) { return resolveTaskAndRun(groupTasks[0]); </ins> } // If there's multiple globs that match we want to show the quick picker for those tasks // We will need to call splitPerGroupType putting globs in defaults and the remaining tasks in none. // We don't need to carry on after here <del> if (taskGroupTasks.length > 1) { </del> <ins> if (globTasksDetected && groupTasks.length > 1) { </ins> return handleMultipleTasks(true); } // If no globs are found or matched fallback to checking for default tasks of the task group <del> if (!taskGroupTasks.length) { taskGroupTasks = await this._findWorkspaceTasksInGroup(taskGroup, false); </del> <ins> if (!groupTasks.length) { groupTasks = await this._findWorkspaceTasksInGroup(taskGroup, false); </ins> } // A single default task was returned, just run it directly <del> if (taskGroupTasks.length === 1) { return resolveTaskAndRun(taskGroupTasks[0]); </del> <ins> if (groupTasks.length === 1) { return resolveTaskAndRun(groupTasks[0]); </ins> } // Multiple default tasks returned, show the quickPicker

Discussion:
Running the command is activating various unnecessary extensions
This is by design - we have to activate any extensions which contribute tasks to fetch the build tasks, if any, that they contribute.
is that the case even if there's a default task configured? I have a suspicion something has changed because building, for example, vscode repo or just a new extension repo with didn't use to activate, e.g., ocaml extension (and there weren't any changes on the ocaml ext side). I would imagine we in general don't need to activate many extensions if there's a default build task?
Note to self - this was happening before the change where we resolve workspace tasks
This is happening because we check for glob tasks as the default - since we aren't sure which it might be, we have to call with no args and that activates all task providers
this originated here seems like not worth it in most cases. this should probably behind a setting
Change:
private readonly _onDidChangeAvailableProfiles = new Emitter<ITerminalProfile[]>(); get onDidChangeAvailableProfiles(): Event<ITerminalProfile[]> { return this._onDidChangeAvailableProfiles.event; } <del> get profilesReady(): Promise<void> { return this._profilesReadyBarrier.wait().then(() => { }); } </del> <ins> get profilesReady(): Promise<void> { return this._profilesReadyPromise; } </ins> get availableProfiles(): ITerminalProfile[] { if (!this._platformConfigJustRefreshed) { this.refreshAvailableProfiles();

Discussion:
<!-- 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.78.0 OS Version: Mac OS 13.3.1 Steps to Reproduce: a new VSCode window using Codespaces. initial terminal window opens a terminal. If I kill that terminal and open a new terminal, I get as expected. I have in my I believe this is a duplicate of these closed issues:
I was expecting this would get fixed as part of , cc
It got , but it only repros using codespaces extension now, before I was able to repro with test resovler extension and remote ssh extension which works as expected now, not sure what's special about codespaces extension as the remote connection logic is the same :thinking:
Ah I can repro now, will take a look, it's because codespaces takes 20s to resolve the remote Edit: There's a :laughing:
PR
/duplicate