jiebi/CodeConvo huggingface dataset:
Code change:
const outDir = path.join(outputRoot, 'media'); async function build() { <del> fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), path.join(outDir, 'codicon.css')); fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.ttf'), path.join(outDir, 'codicon.ttf')); </del> await esbuild.build({ <del> entryPoints: [ path.join(srcDir, 'index.ts') ], </del> <ins> entryPoints: { 'index': path.join(srcDir, 'index.ts'), 'codicon': path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), }, loader: { '.ttf': 'dataurl', }, </ins> bundle: true, minify: true, sourcemap: false,

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/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: stable and from sources Steps to Reproduce: server vscode in safari simple browser :bug: Observe icons don't load (icons load if disable Cross Origin Restrictions in develop menu is checked)
How are you running the server? I see the icons loading in but not on localhost using : ! This seems expected since Safari seems more strict about loading content from localhost in this case
Try codespaces, it repros there too. (For running the server I use ) It works on serverless (i.e. and ) because they are served in a different way I think
I'd also like to see it fixed. It's still reproducible on latest Safari version. <img width="290" alt="image" src="https://user-"
This definitely seems like a webkit bug but I can't put together a minimal repo. The issue is the the codicon font face doesn't go through the service worker during loading despite it's parent css file being loaded by it: ! I also tried debugging the production code in codespaces but Safari's dev tools are pretty much unusable with our minified service worker Instead, I'm going to push a change that inlines the font in the css file to hopefully work around this issue
Looks to be working in latest insiders !
<!-- 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.
Code change:
const outDir = path.join(outputRoot, 'media'); async function build() { <del> fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), path.join(outDir, 'codicon.css')); fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.ttf'), path.join(outDir, 'codicon.ttf')); </del> await esbuild.build({ <del> entryPoints: [ path.join(srcDir, 'index.ts') ], </del> <ins> entryPoints: { 'index': path.join(srcDir, 'index.ts'), 'codicon': path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), }, loader: { '.ttf': 'dataurl', }, </ins> bundle: true, minify: true, sourcemap: false,

Related discussion:
text: 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:
IgnoreBracketedPasteMode = 'terminal.integrated.ignoreBracketedPasteMode', FocusAfterRun = 'terminal.integrated.focusAfterRun', AccessibleViewPreserveCursorPosition = 'terminal.integrated.accessibleViewPreserveCursorPosition', <ins> AccessibleViewFocusOnCommandExecution = 'terminal.integrated.accessibleViewFocusOnCommandExecution', </ins> // Debug settings that are hidden from user

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
} } <del> private static _createMouseTarget(ctx: HitTestContext, request: HitTestRequest, domHitTestExecuted: boolean): IMouseTarget { </del> <ins> private static _createMouseTarget(ctx: HitTestContext, request: HitTestRequest): IMouseTarget { </ins> // console.log(`${domHitTestExecuted ? '=>' : ''}CAME IN REQUEST: ${request}`); <del> // First ensure the request has a target </del> if (request.target === null) { <del> if (domHitTestExecuted) { // Still no target... and we have already executed hit test... return request.fulfillUnknown(); } const hitTestResult = MouseTargetFactory._doHitTest(ctx, request); if (hitTestResult.type === HitTestResultType.Content) { return MouseTargetFactory.createMouseTargetFromHitTestPosition(ctx, request, hitTestResult.spanNode, hitTestResult.position, hitTestResult.injectedText); } return this._createMouseTarget(ctx, request.withTarget(hitTestResult.hitTarget), true); </del> <ins> // No target return request.fulfillUnknown(); </ins> } // we know for a fact that request.target is not null

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/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.88.0-insider in Safari OS Version: macOS Steps to Reproduce: Safari open a file with: to the right of any the cursor goes to the beginning of the line not the end This does not repro in stable
I didn't do any changes the last couple of milestones that could (easily) explain this. Can you reproduce this in the monaco editor? If so, can you do a bisect?
I bisected it to this commit: (the commit before it) does not repro the issue. This wasn't in Monaco editor, I just used run code web:
This commit is just a rename refactoring. It is very unlikely it causes this... This does not reproduce in chrome, right?
The bug does not reproduce in Edge on macOS, but it repros in Safari.
Unfortunately, I don't have access to Safari. Can you double check that this is caused by that commit? Can you locally rename the class back to the original name and see if it still happens? It does not make any sense that this commit would cause this behavior only on Safari.
Ok and I paired a bit on this and are really stumped. Bad news: That commit I called out seems to be a red herring. Good news: we can repro in the Monaco Editor Playground.
Code change:
} } <del> private static _createMouseTarget(ctx: HitTestContext, request: HitTestRequest, domHitTestExecuted: boolean): IMouseTarget { </del> <ins> private static _createMouseTarget(ctx: HitTestContext, request: HitTestRequest): IMouseTarget { </ins> // console.log(`${domHitTestExecuted ? '=>' : ''}CAME IN REQUEST: ${request}`); <del> // First ensure the request has a target </del> if (request.target === null) { <del> if (domHitTestExecuted) { // Still no target... and we have already executed hit test... return request.fulfillUnknown(); } const hitTestResult = MouseTargetFactory._doHitTest(ctx, request); if (hitTestResult.type === HitTestResultType.Content) { return MouseTargetFactory.createMouseTargetFromHitTestPosition(ctx, request, hitTestResult.spanNode, hitTestResult.position, hitTestResult.injectedText); } return this._createMouseTarget(ctx, request.withTarget(hitTestResult.hitTarget), true); </del> <ins> // No target return request.fulfillUnknown(); </ins> } // we know for a fact that request.target is not null

Related discussion:
text: Here's a side by side of two versions of the dev build: <img width="1680" alt="image" src=""You can see when I click to the right of a line, the older (working) build has the correct position here, while the newer broken build has column 1. Here are the links to these versions: Working: Broken: I believe this is out of both of our depths at this point so I'm passing to you This is a regression so I think it should be fixed before we release (assuming I'm not the only one to repro)
Did a bisect using and it points to
In that case, it is most likely .
Code change:
} private static _getLineDecorations(editor: IActiveCodeEditor, anchor: HoverAnchor): IModelDecoration[] { <del> if (anchor.type !== HoverAnchorType.Range) { </del> <ins> if (anchor.type !== HoverAnchorType.Range && !anchor.supportsMarkerHover) { </ins> return []; }

Related discussion:
text: Hovering inlay hints should show problems "underneath": !
Came here to report the same thing https://user-
This happens because inlay hint have their own hover which are anchored on a . The diagnostics hover explicitly checks for that and . Would be OK to pretend to be a "normal" range hover anchor so that I can get all the hovers together? Or should the diagnostics hover not check for the hover type?
The is used both by inlay hints (via ) and ghost text (directly instantiates it). I think in the case of inlay hints you would want that markers are rendered in the hover, but perhaps ghost text wouldn't want that they appear in the hover, it might want to show only these actions: <img width="598" alt="image" src="https://user-"My suggestion would be to add something to to be able to distinguish the two cases.
Can still repro this
Please update this issue with a real code snippet that allows to reproduce this, please update this issue with what you have tried. Thanks
I just found a reduce function in VS Code sources such as and replace the returned value with the void keyword such as
Something like this only gives a squiggle for the return value, not the arguments or anything with inline hints. To clarify, this will only work for squiggles that spawn across inline hints <img width="699" alt="Screenshot 2023-01-26 at 14 49 07" src="https://user-"
Hmm, maybe it's because it's in a function so the return value becomes incorrect? This in <img width="917" alt="image" src="https://user-"
Thanks for updating
Looks good to me. Version: 1.75.0-insider Commit: !
Code change:
import { compareIgnoreCase } from 'vs/base/common/strings'; import { IExtensionIdentifier, IGalleryExtension, ILocalExtension, getTargetPlatform } from 'vs/platform/extensionManagement/common/extensionManagement'; <del> import { ExtensionIdentifier, IExtension, TargetPlatform } from 'vs/platform/extensions/common/extensions'; </del> <ins> import { ExtensionIdentifier, IExtension, TargetPlatform, UNDEFINED_PUBLISHER } from 'vs/platform/extensions/common/extensions'; </ins> import { IFileService } from 'vs/platform/files/common/files'; import { isLinux, platform } from 'vs/base/common/platform'; import { URI } from 'vs/base/common/uri';

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. --When developing an extension, I sometimes mess around with versions, e.g. install an (unpublished) extension with different content using the same version, or going back a version. It can happen then that I can install the extension (via file) successfully, the extension appears, I get the notification to reload VSCode which I accept, and the extension is gone after the reload. It does not load, and it does not appear in the list of installed extensions. There is no warning nor any trace in the extension host output pane. I recently figured out that this appears to be caused by an auto-generated entry in the file, listing the installed version of my extension. There might be a bug here, since it also lists the highest version ever installed. However, this feature request is about the lack of notifications why the extension is not loaded. I would appreciate if you could tell the user, e.g. via a warning during install and maybe during every load, that an extension has been blocked because it's obsolete. Furthermore I suggest listing the extension as installed in the extension pane, as deactivated/obsolete with a warning attached to it.
Can you please provide exact steps to reproduce this behaviour?
I did not mean this as a bug report, but rather as a request to add additional messages telling the user what's going on. However, I've tried to reproduce it and it seems you can get this issue if you do: a for some extension E in version 0.0.1 E in version 0.0.1 from vsix (I'm doing this on a remote machine using the Remote SSH extension). . a for E in version 0.0.2 E in version 0.0.2 that now contains an entry making E in version 0.0.1 obsolete . E in version 0.0.1 . that now contains both an entry making E in version 0.0.1 obsolete as well as version 0.0.2 obsolete. that the extension is not loaded. At this point, you can also install E in version 0.0.2 and it still won't load.
I am not seeing this behaviour.
Code change:
import { compareIgnoreCase } from 'vs/base/common/strings'; import { IExtensionIdentifier, IGalleryExtension, ILocalExtension, getTargetPlatform } from 'vs/platform/extensionManagement/common/extensionManagement'; <del> import { ExtensionIdentifier, IExtension, TargetPlatform } from 'vs/platform/extensions/common/extensions'; </del> <ins> import { ExtensionIdentifier, IExtension, TargetPlatform, UNDEFINED_PUBLISHER } from 'vs/platform/extensions/common/extensions'; </ins> import { IFileService } from 'vs/platform/files/common/files'; import { isLinux, platform } from 'vs/base/common/platform'; import { URI } from 'vs/base/common/uri';

Related discussion:
text: When I install 0.0.1, .obsolete file now contains 0.0.2 version only.
Sorry for taking so long to answer. I've now taken a fresh VM (Ubuntu 22.04) and a new extension (, just modified the so it would package) and could reproduce it. No "Remote - SSH" involved either. The steps: Generate two versions of an extension, 0.0.1 and 0.0.2 Install VS Code. At this point, does not exist yet. Install 0.0.1 and reload. Install 0.0.2 and reload. This creates the file with a single entry . Install 0.0.1 and reload. The file now contains . The extension is not loaded and does not appear in the list of installed extensions. Even if you "only" end up with an entry for version 0.0.2, this would still probably cause an issue if you try to re-install 0.0.2 since there are no diagnostics emitted - neither during installation nor during startup.
Ok there is a bug at the last step - Installing 0.0.1 shall not add 0.0.1 to the file. This bug happens only when the has no set. Can you please set the property in the and retry?
To verify: Formulate an extension without property in Generate a VSIX 0.0.1 with version Generate a VSIX 0.0.2 with version Install VSIX 0.0.1 and make sure 0.0.1 version is installed Install VSIX 0.0.2 and make sure 0.0.2 version is installed Again Install VSIX 0.0.1 and make sure 0.0.1 version is installed
Code change:
import { localize } from 'vs/nls'; import { URI } from 'vs/base/common/uri'; import { IResourceEditorInput, IEditorOptions } from 'vs/platform/editor/common/editor'; <del> import { IEditorPane, IEditorCloseEvent, EditorResourceAccessor, IEditorIdentifier, GroupIdentifier, EditorsOrder, SideBySideEditor, IUntypedEditorInput, isResourceEditorInput, isEditorInput, isSideBySideEditorInput, EditorCloseContext, IEditorPaneSelection, EditorPaneSelectionCompareResult, EditorPaneSelectionChangeReason, isEditorPaneWithSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection, IEditorWillMoveEvent } from 'vs/workbench/common/editor'; </del> <ins> import { IEditorPane, IEditorCloseEvent, EditorResourceAccessor, IEditorIdentifier, GroupIdentifier, EditorsOrder, SideBySideEditor, IUntypedEditorInput, isResourceEditorInput, isEditorInput, isSideBySideEditorInput, EditorCloseContext, IEditorPaneSelection, EditorPaneSelectionCompareResult, EditorPaneSelectionChangeReason, isEditorPaneWithSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection, IEditorWillMoveEvent, GroupModelChangeKind } from 'vs/workbench/common/editor'; </ins> import { EditorInput } from 'vs/workbench/common/editor/editorInput'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { GoFilter, GoScope, IHistoryService } from 'vs/workbench/services/history/common/history';

Related discussion:
text: Steps to Reproduce: recently opened ("Clear Editor History") quick open and search for a file (such as a TS file) to see symbols (notice how the file opens in the background) to a symbol = when you open quick open again, the file is not part of the recently opened section //cc this is a regression from the transient work we did
Code change:
this._terminalTabs = []; this._configHelper = this._instantiationService.createInstance(TerminalConfigHelper); ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the

Related discussion:
text: With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.
Code change:
import { NotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookProvider'; import { NotebookPerfMarks } from 'vs/workbench/contrib/notebook/common/notebookPerformance'; import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; import { localize } from 'vs/nls'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </ins> export interface NotebookEditorInputOptions { startDirty?: boolean;

Related discussion:
text: Testing a new notebook and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , :bug: The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
can you maybe check from the notebook side?
Luna paint behaves similarly with one extra step: a new image and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , (different) and the switch profile operation is blocked switch profiles again The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
Somehow today I cannot reproduce an issue with insiders: ! Please give me more detailed steps and see if you still find this.
still seeing it. Did you try making edits after switching? that's when the dirty indicator doesn't show up anymore. ! I saved as a different filename in the gif, but keeping the untitled filename still doesn't show a dirty indicator, nor does it auto-save.
This seems to me like something notebooks need to handle better: if you enter an extension host that does not have the notebook extension and you make edits, the editor should probably not allow that. I.e. the editor should maybe turn readonly once the extension is disabled or not present.
- the notebook extension is built-in so it's still available in an empty profile. The repro steps can even start with an empty profile -and make an edit to the first cell profile to default and save as 1.ipynb when prompted an edit in the notebook :bug: file is not dirty
oh nice, sounds like an issue related to EH restart then, will update the title With your working copy knowledge you might be even able to figure this out ;)
It looks like the issue in the notebook scenario is that it's calling save directly on the workingCopy in the : In the untitled case, that will delegate to saveAs, which will dispose the untitled workingcopy without opening a new editor with the resulting . The editor is left open with its underlying WorkingCopy disposed. For non-built-in custom editors though, it seems like we should just close them if we don't know if they will be supported in the new profile.
Code change:
import { NotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookProvider'; import { NotebookPerfMarks } from 'vs/workbench/contrib/notebook/common/notebookPerformance'; import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; import { localize } from 'vs/nls'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </ins> export interface NotebookEditorInputOptions { startDirty?: boolean;

Related discussion:
text: I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)