jiebi/CodeConvo huggingface dataset:
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import 'vs/css!./media/releasenoteseditor'; </ins> import { onUnexpectedError } from 'vs/base/common/errors'; import { OS } from 'vs/base/common/platform'; import { URI } from 'vs/base/common/uri';

Discussion:
Issue Type: <bBug</bRelease Notes from Help menu it Release Notes doesn't show an icon on its normal tab, the pinned one is empty. VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:19:54.327Z) OS version: Windows_NT x64 10.0. ! Compare its appearance to that of my adjacent pinned tab, which is my file (very handy to be able to pin it, kudos to ) <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.669 --- <!-- score: 0.543 --- <!-- score: 0.532 --- <!-- score: 0.455 --<!-- potentialduplicatescomment --
This actually looks like a bug to me, because release notes should have the product icon. Looking into devtools I see it being referenced: ! However, this file does not exist on disk likely because it gets inlined, as you can see in the welcome tab where the icon appears properly: ! Assigning a couple of people to check this.
I should add that I indeed moved this icon to a new place (we had many copies of it). So it could be a regression from that work.
so this is a regression from my push but I think the way the icon is used in here is not ideal because it prevents the image from being inlined: A better solution would be to have it referenced from CSS like we do e.g. in the welcome page: However this would require some name to appear as part of the label we could override. I am not sure how to pass a resource name to the webview? Currently it looks like we add a UUID: ! Open for ideas. Last resort is to just bring back that icon, but then we have it duplicate as before.
This actually has nothing to do with pinned tabs as it appears blank normally: !
Change:
assert.strictEqual(didSave, true, `FAILED to save${doc.uri.toString()}`); <ins> assert.ok(closed); </ins> assert.ok(closed === doc); assert.ok(!doc.isDirty); assert.ok(fs.existsSync(path));

Discussion:
Failed in
Again, could be a regression from , looks like this test failure is relatively new. One actual change from is that will not reach without yielding once, due to the new here: Since we no longer disable the editor override here: If there is any code in the renderer that relied on the previous behaviour, maybe that change made the tests more flaky now?
My theory is that possibly is actually and so pushing a change to assert it is there.
This failed again for web in: Given my change is in, it looks like literally even though we have document from the event, it is not the same as : I am pushing a change to compare the URIs of the two and see what they are.
I see no failure since, let's close until we hit this again.
Failed again in: This looks as if a document from a previous test run appears in our event listener here: I guess we cannot guarantee that the event that comes in is for the closed editor, there maybe multiple. So an idea to fix this is to keep closed documents in an array for the test and try to find the one we expect:
Change:
import { ITextModel } from 'vs/editor/common/model'; import { getHover } from 'vs/editor/contrib/hover/getHover'; import { dispose, IDisposable } from 'vs/base/common/lifecycle'; <ins> import { EditOperation } from 'vs/editor/common/core/editOperation'; import { basename } from 'vs/base/common/path'; </ins> const HOVER_DELAY = 300; const LAUNCH_JSON_REGEX = /.vscode/launch.json$/;

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44.0 OS Version: Win 10 1909, .720 Steps to Reproduce: a multi root workspace panel -Add configuration (workspace)... Expected to see a dropdown list showing supported debug configurations (just like in single root mode). Actual behavior is that only the .code-workspace file gets focus. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Aha, for the the Add configuration (workspace) you would like the debug configuration providers to be called. This is a fair feature request, however not on the immedaite plan thus assigning to backlog. We would be open to a pr that adds this. If you are intersted let me know and I can provide a code pointer
Sure I'd like to make the change. And it would be great if you can give me some code pointers.
Here's a code pointer Thanks
After looking at the code, I found that the suggestions wouldn't pop up if the "configurations" field doesn't exist in single root mode as well. So I'm planning to add some code to insert launch configure lines when they don't exist. Since I didn't find anywhere in this code base inserting some texts at a certain position into a file, do you have an example (I think settings is already doing something like this)?
If you have an instance of an you could for example.
Change:
import { createRandomIPCHandle } from 'vs/base/parts/ipc/node/ipc.net'; import { ILogService } from 'vs/platform/log/common/log'; import { RemoteAgentConnectionContext } from 'vs/platform/remote/common/remoteAgentEnvironment'; <del> import { IPtyService, IShellLaunchConfig, ITerminalProfile, ITerminalsLayoutInfo } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { IPtyService, IShellLaunchConfig, ITerminalProfile } from 'vs/platform/terminal/common/terminal'; </ins> import { IGetTerminalLayoutInfoArgs, ISetTerminalLayoutInfoArgs } from 'vs/platform/terminal/common/terminalProcess'; import { IWorkspaceFolder } from 'vs/platform/workspace/common/workspace'; import { createRemoteURITransformer } from 'vs/server/remoteUriTransformer';

Discussion:
Also repro's in stable
unsure when this started happening. I don't see any open issues about it, which makes me think this is expected in WSL?
was last working in stable 1.59
and because it was broken in stable 1.60, we can narrow it down - the breaking change happened in August
looks like perhaps a race condition - get layout info is called w the correct workpsaceId, but then set layout info is called so might be wiping out the stored info before the reconnect can occur.
I open a terminal in a Remote-SSH window, reload the window, it is not reconnected
still doesn't work for WSL. based on my investigation, the pty service gets re-created when the window is reloaded, thus losing the and maps
when connected to localhost via ssh, reloading does persist the terminals but I thought this would still be using the ... !
Yep !
Also working for me in codespaces https://user-
It does work in WSL. interestingly, other state isn't persisted that should be though (see the layout change) !
this works on all remote platforms based on my testing. i saw a few times reloading WSL didn't work, but now cannot reproduce
Oh cool, I thought the situation was much worse. I'll reopen to verify on my side since we definitely want to make sure this is working everywhere
All seems to work
verified
Change:
private _mouseMoveDisposable: IDisposable; private _widgetManager: TerminalWidgetManager; private _initialCwd: string; private _localLinkPattern: RegExp; constructor(

Discussion:
The underline also isn't appearing <img width="676" alt="screen shot 2018-05-18 at 12 12 49 pm" src="https://user-"
I also encountered this problem on Ubuntu 16.04, underline is not displayed on std input , and std output for Terminal. Hope can be fixed. Version 1.24.1 Commit Date 2018-06-13T17:47:35.732Z Shell 1.7.12 Renderer 58.0.3029.110 Node 7.9.0 Architecture x64
Hi! After some testing I found that the problem (regarding tooltip location) seems to be that, when emits the event, the and properties of the fired instance are zero: ! I believe this is because the DOM element which fires the event is the rendering the character instead of some element with the size of the entire terminal (like the in the default renderer). In order to solve it, I  to and styles so the event don't target those objects and the becomes the , provider. do you think it is a good solution? I can make a PR, if you want. Edit: Those changes should be made on the package (And maybe this issue should be there also?)
Regarding the underline don't appearing I'm trying this solution , and it seems to work (I'm going to sleep right now, but tomorrow I'll make some testing). Do you think it's a feasible solution?
, we probably don't want to handle the tooltip location in since should just be providing all the info it has in the mouse event without making specific assumptions about how that info will be used. I'll let comment on the underline
I made some comments on the underline in that commit , looks pretty close to what we're after. I created to track this, a PR would be fantastic! You would also want to remove the line in that says link underlines are not supported.
Underline don't appearing was fixed in We should wait for 's 3.8.0 release in order to update and close this issue, right?
I've already pulled in your changes, we'll close this off when is merged.

Hmm, something is still a bit off, mousing over and pausing on the bottom few pixels will show the tooltip in the correct position but the pixels above will show the tooltip where it should be for the line above ! !
I still have no idea why this is happening but this is what I got so far: Target of the event in the expected behavior scenario: Target of the event in the unexpected behavior scenario:
PR out upstream which should fix this:
I can no longer reproduce.
Change:
export class FolderMatchWithResource extends FolderMatch { <ins> protected _normalizedResource: Lazy<URI>; </ins> constructor(_resource: URI, _id: string, _index: number, _query: ITextQuery, _parent: SearchResult | FolderMatch, _searchModel: SearchModel, _closestRoot: FolderMatchWorkspaceRoot | null, @IReplaceService replaceService: IReplaceService, @IInstantiationService instantiationService: IInstantiationService,

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 <!-- 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.2 OS Version: Windows 11 22H2 (.1778) Steps to Reproduce: ! a WSL folder from the command line with the argument --remote, with a trailing forward slash. Example: to search all files for any search term. The files will not appear. ! a WSL folder from the command line with the argument --remote, without a trailing forward slash. Example: to search all files for any search term. The files will appear. !
Change:
} function canRevive(reviver: WebviewResolver, webview: WebviewInput): boolean { <del> if (webview.isDisposed()) { return false; } </del> return reviver.canResolve(webview); }

Discussion:
Webviews appear to not restore via or running the command: a webview, like a PR/welcome page/release notes tab tab :bug: tab is skipped and goes to next This is also affected by pinned tabs but I assume it's related to the reopen command.
This is intentional because there is no way currently a non-file based editor can signal that it can simply be restored. Check is here: However this could possibly be improved by simply asking the editor input factory to serialize the editor and then bring it back, I can play around with that approach. not sure that makes sense to you, is it safe to serialize any webview via its factory and bring it back from that state?
Upon second thought, I think my proposed idea is also not good because when an editor closes, assuming that you can serialize it may be risky. I think we would need some new infrastructure to support this scenario.
with the change in , we are now asking the editor input factory to serialise an editor when it closes to support for opening it again. However it looks like webviews are not being serialized when they got closed, which maybe is for a good reason. If we cannot support this easily, then I suggest to close this feature, otherwise please try it out and see what is missing.
Just want to throw my two cents in/use case in. I came here because I updated to 1.47.0-insider from 1.46.0-insider, the initial launch opened the Release Notes: 1.47.0-insider tab, I closed it by accident, then tried to open it again with Ctrl+Shift+T. Presumably that page is a webview and suffers from this. Easy enough to get it back via Help -Release Notes, but the expected actions did not work. Edit: Seems release notes are a different problem, my bad!
Not enabled for the release notes at the moment but should now work for markdown previews
Change:
async $watch(extensionId: string, session: number, resource: UriComponents, unvalidatedOpts: IWatchOptions): Promise<void> { const uri = URI.revive(resource); <del> const correlate = Array.isArray(unvalidatedOpts?.excludes) && unvalidatedOpts.excludes.length > 0; // TODO@bpasero for now only correlate proposed new file system watcher API with excludes </del> const opts: IWatchOptions = { ...unvalidatedOpts

Discussion:
Testing Extension Event Log
I actually wasn't sure if the glob pattern was supposed to be excluding this file in the default watcher excludes but even specifying the glob directly like this doesn't exclude:
the default exclude is actually so that we can still detect changes to top level folder. So your first observation is actually expected. It would only ignore for deeper folder structures within .
Your second case is a nice find though: you provide an explicit exclude list and the events that you see are actually from the default workspace file watcher. should address that.
Change:
async getLocalExtensions(profile: IUserDataProfile): Promise<IProfileExtension[]> { return this.withProfileScopedServices(profile, async (extensionEnablementService) => { <del> const result: Array<IProfileExtension & { displayName?: string }> = []; </del> <ins> const result = new Map<string, IProfileExtension & { displayName?: string }>(); </ins> const installedExtensions = await this.extensionManagementService.getInstalled(undefined, profile.extensionsResource); const disabledExtensions = extensionEnablementService.getDisabledExtensions(); for (const extension of installedExtensions) {

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, actually this issue has nothing to do with extensions <!-- 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.79.1 (user setup) Commit: Date: 2023-06-12T16:14:05.102Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: Connect to WSL(Ubuntu ) Profiles =Show Contents... <img width="286" alt="image" src=""As you can see, the extensions of the profile are duplicated. The reason I found is I installed the extensions in WSL again. Maybe It's not a bug. But, the profile should distinguish between extensions installed in the host and WSL. Maybe like this: ESLint - host Disabled ESLint - WSL So that I know which place I install the extension and its enabled/disabled status. When I open the detail page of the duplicated extensions, both of them display an "Extension is enabled on 'WSL: Ubuntu-22.04'" message. What I expect is: The extension is installed and enabled on the host, the message should be "Extension is enabled". The extension is installed and enabled on the WSL, the message should be "Extension is enabled on 'WSL: Ubuntu-22.04'". Does it make sense?
Related on Stack Overflow: .

Let me know if there's any debugging steps or details you'd like be to solicit from people in my answer there.
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
what's it a duplicate of?
I am sorry, I remembered this bug and thought there is an issue already, but there is not. Reopened it.
I guess duplicate only shows for extensions installed in both local VS Code and remote hosts. !
Fixed: Contents show only one instance of the extension
Change:
".ino", ".inl", ".ipp", <ins> ".ixx", </ins> ".hpp.in", ".h.in" ],

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. --extensions on C++ source files can be used to inform Visual Studio that this file is a C++ module interface file, . However, in Visual Studio Code, they are not automatically detected as C++ code. Code should mark files with the extension as C++.
Change:
const searchIcon = renderIcon(Codicon.search); searchIcon.classList.add('search-icon'); <ins> this.workspaceTitle.classList.add('search-label'); </ins> this._updateFromWindowTitle(); reset(this.label, searchIcon, this.workspaceTitle); this._renderAllQuickPickItem(container);

Discussion:
Trying Perhaps we could default to some subset of the prompt text under some media query or other window size condition. One possible option would be to shorten the [Action | Folder name] pattern to just the action. E.g. "Search hello-world" -"Search" <img width="461" alt="CleanShot 2022-05-13 at 09 59 13 src="https://user-"<img width="472" alt="CleanShot 2022-05-13 at 10 03 30 src="https://user-"cc for other ideas
Small update: based on standup-feedback I swapped "Search" with the corresponding icon. That should give some more room but the problem still exists... I lean towards using the usual ellipsis for text overflow <img width="473" alt="Screenshot 2022-05-16 at 14 02 46" src="https://user-"
This is how it looks with ellipsis. *it actually looks better - the recording shows some padding issues when space is tight https://user-
Looks great! Especially if there more padding L/R per your edit.
Change:
// See http://go.microsoft.com/fwlink/?LinkId=759670 // for the documentation about the jsconfig.json format "compilerOptions": { <del> "module": "commonjs" </del> <ins> "target": "es6" </ins> }, "exclude": [ "node_modules",

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --For labels in extensions, using e.g. . However, there seems to be no way to show the literal text in a label, i.e. escaping the icon syntax. This is relevant for the Vim extension, as it makes it impossible to e.g. search/replace icon codes using the Vim commandline input when developing an extension: ! See
May I know where/which view in VS code this is being rendered?
In the screenshot it's a , but according to the same would apply to hovers and QuickPickItems too
should do it.
Hm, that seems to work indeed. I thought I had tried that, but apparently not? Thanks, closing this then. I opened to document this.
Change:
return this.instantiationService; } <del> private saveState(): void { </del> <ins> private saveState(e: IWillSaveStateEvent): void { </ins> if (this.zenMode.active) { this.storageService.store(Workbench.zenModeActiveStorageKey, true, StorageScope.WORKSPACE); } else { this.storageService.remove(Workbench.zenModeActiveStorageKey, StorageScope.WORKSPACE); } <ins> if (e.reason === WillSaveStateReason.SHUTDOWN && this.zenMode.active) { const zenConfig = this.configurationService.getValue<IZenModeSettings>('zenMode'); if (!zenConfig.restore) { // We will not restore zen mode, need to clear all zen mode state changes this.toggleZenMode(true); } } </ins> } dispose(): void {

Discussion:
zen mode vscode, start vscode that zen mode properly is not restored excepted centered layout. Centered layout should also be inactive (since is )
acutally your change from that commit caused this. You removed that the zen mode gets out of zen mode when you are exiting. Let me look into a fix
the idea is to only write to local storage from and not . Is writing any data to local storage? If not, this change seems fine.
it is writing data to local storage. I just need to write it before the workbench goes down. So I will react on instead of . That event will only get fired once before the workbench shuts down?
yeah currently that is right. In the future when we decide to store state more periodically we might decide to call this method more often though to preserve state even if Code is crashing. I do not understand why you have to leave Zen mode on shutdown because you will restore it on the next startup, no? Given that, I suggest to NOT leave Zen mode on shutdown but rather simply NOT restore it on next startup. Isn't that easier?
thanks for clarification. I can not simply NOT restore it on next startup since the subsets of zen mode will have written state to storage. Example: User enters zen mode -zen mode tells Sidebar hide yourself. Sidebar writes that into storage Next vscode start -zen mode is not restored, Sidebar is still hidden because he wrote into storage once we activated zen mode. Due to how the feature is designed it needs to explicitly tell the underlying parts to hide or show. We could change this, but that would require that every underlying part is aware of zen mode which might overcomplicate things. Suggestions on how to tackle this are also welcome Thanks
got it. I pushed a change so that carries a with a reason you can ask for. On shutdown that reason will be set and so you can do the same things as before. As long as you are not running async code that accesses storage late, things should be fine. The goal should be that storage layer gets accessed either: when changes happen (e.g. workbench layout does that) or (which currently only fires on shutdown but might fire periodically later)
this works.

However there was a corner case for the reload since we were restoring zen mode always on reload and in your event i was not getting if it is a reload or regular shutdown Though fixed it by not auto restoring zen mode on reload. I think this is perfectly fine. Users should set zenMode.restore to true if they want this
thank you