jiebi/CodeConvo huggingface dataset:
Change:
const tokens = this.engine.parse(text); const headings = tokens.filter(token => token.type === 'heading_open'); <del> const symbols = headings.map(heading => { </del> <ins> return headings.map(heading => { </ins> const lineNumber = heading.map[0]; const line = document.lineAt(lineNumber + offset); const location = new vscode.Location(document.uri, line.range);

Discussion:
The current behaviour of Code's Markdown previewer when clicking a relative link is actually a bit cryptic: it attempts to open the file relative to the user's home path with the system's application of choice. This will commonly lead to errors being dispatched because the file cannot be found. If I have the following Markdown: Clicking the link will make my system attempt to open . Given that even , I strongly believe that they should be supported here. Such links should instead be relative to the markdown file's directory and open the linked file using the Code editor.
+1; opening markdown files by clicking a (relative) link in the preview would be a very powerful feature both for writing developer documentation (split into individual files by topic) for a project, but also for viewing that documentation.
Related: Is this behavior something vscode could change for its markdown preview?
Change:
*/ private ensureFencedCodeBlocksTerminated(content: string): string { const lines = content.split('n'); <del> let inCodeBlock = false; </del> <ins> let codeBlockState: undefined | { readonly delimiter: string; readonly indent: string }; </ins> for (let i = 0; i < lines.length; i++) { const line = lines[i]; <del> if (line.startsWith('```')) { inCodeBlock = !inCodeBlock; </del> <ins> if (codeBlockState) { if (new RegExp(`^s*${codeBlockState.delimiter}s*$`).test(line)) { codeBlockState = undefined; } } else { const match = line.match(/^(s*)(`{3,}|~{3,}|)/); if (match) { codeBlockState = { delimiter: match[2], indent: match[1] }; } </ins> } } // If we're still in a code block at the end of the content, add a closing fence <del> if (inCodeBlock) { lines.push('```'); </del> <ins> if (codeBlockState) { lines.push(codeBlockState.indent + codeBlockState.delimiter); </ins> } return lines.join('n');

Discussion:
Steps to Reproduce: As copilot to generate a response that includes fenced code blocks inside of a list Bug The code block is rendered as text during progressive rendering until we hit the end of the block
Change:
CommandsRegistry.registerCommand({ id: quickAccessNavigatePreviousInTerminalPickerId, handler: getQuickNavigateHandler(quickAccessNavigatePreviousInTerminalPickerId, false) }); // Register workbench contributions <del> const workbenchRegistry = Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench); workbenchRegistry.registerWorkbenchContribution(TerminalMainContribution, LifecyclePhase.Restored); workbenchRegistry.registerWorkbenchContribution(RemoteTerminalBackendContribution, LifecyclePhase.Restored); </del> <ins> // This contribution blocks startup as it's critical to enable the web embedder window.createTerminal API registerWorkbenchContribution2(TerminalMainContribution.ID, TerminalMainContribution, WorkbenchPhase.BlockStartup); registerWorkbenchContribution2(RemoteTerminalBackendContribution.ID, RemoteTerminalBackendContribution, WorkbenchPhase.AfterRestored); </ins> // Register configurations registerTerminalPlatformConfiguration();

Discussion:
changed to move to but this caused a feature for Codespaces to stop working where the terminal will start streaming in the init logs before the workbench has fully loaded. Ideally we would start it up on Starting only on remote, if we can't do that we need to move it back to Starting in the meantime. cc
We know if we are connected to a remote from the environment service via probing for .
We don't have access to services at workbench contrib registration do we?
no, but you could have 1 eager workbench contrib that depends on the environment service to decide if a second thing should get instantiated or not.
Marked verified, only can properly verify it
this seems to still be failing, the terminal does not show up until the codespace is fully created and the workbench initialized
Verified by
Change:
append(keyboardMarker, $('span.title', {}, `${commandAndGroupLabel} `)); } <del> if ((options.showKeys ?? true) || (command && (options.showKeybindings ?? true))) { </del> <ins> if ((options.showKeys ?? true) || (commandDetails && (options.showKeybindings ?? true))) { </ins> // Fix label for arrow keys keyLabel = keyLabel?.replace('UpArrow', '↑') ?.replace('DownArrow', '↓')

Discussion:
Found while verifying
Yeah this has always been the case. I think it's due to registerAction vs registerCommand. Very confusing. We should investigate whether there's another way to get the commands, other than .
Take a look at this PR fixing this. Let me know if you have feedback for how the issue is solved.
Verification: Some commands are still not showing up since they register against the command registry without any description. This needs fixing at each command registration. But the fix makes sure certain commands start getting labels, like pressing <kbdCmd N</kbdto create a new untitled file.
as you mentioned some shortcut like + or + are still not visible - is there issue where that this shortcuts can be reported or progress regarding this fix tracked?
Change:
replacePattern = parseReplaceString('newfoo_newbar-abc'); actual = replacePattern.buildReplaceString(['Foo_Bar-abc'], true); assert.equal(actual, 'Newfoo_newbar-abc'); <ins> replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['foo_Bar'], true); assert.equal(actual, 'newfoo_Newbar'); replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['foo_BAR'], true); assert.equal(actual, 'newfoo_NEWBAR'); </ins> }); });

Discussion:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)
Change:
this.toDispose.push(this.editorService.onDidVisibleEditorsChange(() => { const editors = this.editorService.visibleEditors; let shouldFire = false; <del> this.uriVisibilityMap.forEach((visible, uri) => { if (!visible) { editors.forEach(e => { if (e.resource && this.uriIdentityService.extUri.isEqualOrParent(e.resource, uri)) { // A filtered resource suddenly became visible since user opened an editor shouldFire = true; } }); </del> <ins> for (const e of editors) { if (!e.resource) { continue; </ins> } <del> }); this.editorsAffectingFilter.forEach(e => { </del> <ins> const stat = this.explorerService.findClosest(e.resource); if (stat && stat.isExcluded) { // A filtered resource suddenly became visible since user opened an editor shouldFire = true; break; } } for (const e of this.editorsAffectingFilter) { </ins> if (!editors.includes(e)) { // Editor that was affecting filtering is no longer visible shouldFire = true; <ins> break; </ins> } <del> }); </del> <ins> } </ins> if (shouldFire) { this.editorsAffectingFilter.clear(); <del> this.uriVisibilityMap.clear(); </del> this._onDidChange.fire(); } }));

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. --Related Issues: <!-- 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. --- VS Code Version: 1.54.1 OS Version: Linux x64 5.8.0-44-generic Steps to Reproduce: a root folder (files-exclude-sample) that folder create two nested folders (child1, child2) root folder (files-exclude-sample), create a workspace definition file (files-exclude-) root folder (files-exclude-sample), create a .vscode folder .vscode folder create a file to previous steps, just clone this GitHub repo: VSCode, open the workspace (files-exclude-) looks ok. You have tree root folders (files-exclude-sample, child1 and child2) ! you expand all three folder you can see something like ! specified in root folder , child1 and child2 are excluded from child1 folder child1 folder is collapsed (not removed from explorer tree) and it appears inside root folder (files-exclude-sample) folder ! expected behavior is that child1 is not collapsed and it does not appear inside root folder <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
the owner of the file explorer is
I acknowledge this issue. MR workspace support with when one root folder is a subfolder of another root folder has some issues. If somebody is passionate about fixing this let me know and I can provide pointers
Created fixing this
Thanks to a great pr by this is now fixed
Change:
const searchBoxLabel = localize('SearchSettings.AriaLabel', "Search settings"); <del> const SETTINGS_AUTOSAVE_NOTIFIED_KEY = 'hasNotifiedOfSettingsAutosave'; </del> const SETTINGS_EDITOR_STATE_KEY = 'settingsEditorState'; export class SettingsEditor2 extends EditorPane {

Discussion:
I am sure by now everyone got this: !
I used to get issues about people not sure whether settings were saved, now I don't. You should only see it once in a new user data dir. I think it's useful, I'd prefer to keep it.
I think given our latest move to reduce notifications we should revisit this. //cc
Agree. would you be open to remove this notification now? This only happens in JSON settings? This one is advanced and maybe those users do not need help?
This happens with our standard settings editor: !
Oh I misunderstood, then I would definitely remove this notification. Most UI now days do not have an Apply button and none of the notify that you do not have to click apply for the setting to be applied. did we run some user studies where participants would get confused if their settings get saved? Could we maybe remove this notification and run a short study to gather some impressions. Reopening this issue for discussion
As I remember, this came directly from user studies. But that was 3 years ago and maybe we can just assume that people are used to it now? You will also only get it once.
I don't remember the details from the user study but I think it would be fine to remove this and then also follow up with a short study.
cool. do you mind if we remove this in May debt week, so we have the whole May milestone to gather feedback and maybe do a short study?
Since I noticed this again now in endgame week with fresh installs, decided to put up a PR with the notification removed in
Awesome, thanks for doing that
verified
Change:
await stableApp.workbench.editors.newUntitledFile(); const untitled = 'Untitled-1'; <del> const textToTypeInUntitled = 'Hello, Untitled Code'; </del> <ins> const textToTypeInUntitled = untitled; </ins> await stableApp.workbench.editor.waitForTypeInEditor(untitled, textToTypeInUntitled); const readmeMd = 'readme.md';

Discussion:
Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.

This was nicely uncovered by our internally implements a logic that throws an error in case multiple calls are made in parallel and a folder was created in the meantime. This is due to the fact that throws when a directory already exists. However, node's own implementation does not throw with the recurse option set to . We should align our implementation and not throw when a folder already exists.
Verification: run our smoke test and see how the hot-exit tests succeed.
Change:
editPresentation: prop.editPresentation, order: prop.order, defaultValueSource, <del> isLanguageTagSetting </del> <ins> isLanguageTagSetting, categoryLabel, categoryOrder </ins> }); } }

Discussion:
Tested on Insiders Build 1.65.0 and Build 1.64.2. If an extension's settings are viewed, the presentation order is respected, but _only if the "Search settings" bar is empty. If the search bar contains anything, including the name of the extension (matching all settings for that extension), the presentation order is alphabetical. Given that the presentation can still be controlled by the selected extension name in the left menu, it would seem logically possible to respect the sort ordering within an extension settings group. Examples: Following ordering (search area blank): ! Not following ordering: !
Verification steps: or write an extension with settings where the settings group and the individual settings use fields to determine the order. An example is at Also make the setting keys similar so that they can show up under the same search query. the extension, navigate to the Settings editor, and clear the search widget. that the settings for that extension are displayed in the expected order. a query to the search widget such that those extension settings still show up. that the filtered settings for that extension show up in the same order as in step 3.
Tested just now on LGTM
Change:
opts.selection = activeTextEditor.selection; } <ins> if (!left) { const document = await workspace.openTextDocument(right); await window.showTextDocument(document, opts); return; } </ins> return await commands.executeCommand<void>('vscode.diff', left, right, title, opts); }

Discussion:
VSCode Version: Code - Insiders 1.13.0-insider (, 2017-05-26T05:14:23.944Z) OS Version: Windows_NT ia32 10.0. Currently you can multi-select items in the Git files view and if you right-click, the & menu items will only open the file/change of the focused item, with the stage/unstage command work with the whole selection. It would be great to have these 2 command act upon the whole selection.
Change:
constructor() { super({ id: CONFIGURE_TRUST_COMMAND_ID, <del> title: { original: 'Configure Workspace Trust', value: localize('configureWorkspaceTrust', "Configure Workspace Trust") }, </del> <ins> title: { original: 'Configure Workspace Trust Settings', value: localize('configureWorkspaceTrustSettings', "Configure Workspace Trust Settings") }, </ins> precondition: ContextKeyExpr.and(WorkspaceTrustContext.IsEnabled, ContextKeyExpr.equals(`config.${WORKSPACE_TRUST_ENABLED}`, true)), category: WORKSPACES_CATEGORY, f1: true

Discussion:
<img width="368" alt="CleanShot 2022-07-18 at 08 28 16 src="https://user-""Configure" and "Manage" are really similar to each other and I had a hard time knowing which one opened what, which caused me to open the wrong one. "Configure" opens the settings UI with a query, and "Manage" opens a custom editor. My proposal would be to change "Configure Workspace Trust" to "Workspace Trust Settings" to make it explicit.
I'd actually like to tweak your proposal to "Manage Trusted Workspaces" and "Configure Workspace Trust Settings"
Change:
...includeUntracked ? this.untrackedGroup.resourceStates.map(r => r.resourceUri.fsPath) : []]; return await this.run(OperationKind.Stash, async () => { <del> this.repository.createStash(message, includeUntracked); </del> <ins> await this.repository.createStash(message, includeUntracked); </ins> this.closeDiffEditors(indexResources, workingGroupResources); }); }

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. --When I don't have any commits, running doesn't do anything, there are no prompts and it can be confusing. In the output, you can see the hint given by Git. <img width="2032" alt="Xnip2022-05-15_02-45-50" src="https://user-"
Instead of a notification maybe add a clause to the command so that it is only enabled when there is an initial commit and there are changes to stash.
Change:
label: languageId, description: `(${label})`, filepath: joinPath(dir, `${languageId}.json`), <del> hint: true </del> <ins> hint: true, iconClasses: getIconClassesForLanguageId(languageId) </ins> }); } }

Discussion:
Type: <bBug</bSteps to Reproduce: Visual Studio Code. to and select . the language for any selected file by running the command (). the dropdown list from step 2 with the dropdown list from step 3. Expected Behavior: Both dropdown lists should appear consistent, as they serve a similar purpose. Specifically, the list should include icons for the language identifiers, just as the list does. Here's what it looks like: VS Code version: Code 1.90.2 (, 2024-06-18T22:33:48.698Z), Code - Insiders 1.91.0-insider (, 2024-06-19T05:51:22.778Z) OS version: Linux x64 6.5.0-41-generic snap Modes: <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Change:
public goToBottom(): void { this._hover.scrollbar.setScrollPosition({ scrollTop: this._hover.scrollbar.getScrollDimensions().scrollHeight }); } <del> public escape(): void { this._editor.focus(); } </del> } export class EditorHoverStatusBar extends Disposable implements IEditorHoverStatusBar {

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 Insiders Version: VS Code Version: OS Version: Ubuntu 22.04.2 LTS Steps to Reproduce: This issue is identical to which was supposedly fixed by . I do not have a windows machine atm, so I cannot test if this is exclusively an issue with the snap-installed version of vscode, but I highly doubt it is. does give focus back to editor, but that's just a workaround.
Hi thanks for filing the issue. It appears this is a regression from the previous work done on making the hover resizable. A fix will be made.
Change:
'!**/*.icns', '!**/*.xml', '!**/*.sh', <ins> '!**/*.zsh', </ins> '!**/*.txt', '!**/*.xpm', '!**/*.opts',

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 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.65.0-insider OS Version: MacOS12.2.2 Steps to Reproduce: with setting new terminal <img width="1440" alt="image" src="https://user-"
Thanks, we're aware of this issue and have been working toward its resolution
Change:
} // file system error <del> throw new FileSystemError(err.message, err.name as files.FileSystemProviderErrorCode); </del> <ins> switch (err.name) { case files.FileSystemProviderErrorCode.FileExists: throw FileSystemError.FileExists(err.message); case files.FileSystemProviderErrorCode.FileNotFound: throw FileSystemError.FileNotFound(err.message); case files.FileSystemProviderErrorCode.FileNotADirectory: throw FileSystemError.FileNotADirectory(err.message); case files.FileSystemProviderErrorCode.FileIsADirectory: throw FileSystemError.FileIsADirectory(err.message); case files.FileSystemProviderErrorCode.NoPermissions: throw FileSystemError.NoPermissions(err.message); case files.FileSystemProviderErrorCode.Unavailable: throw FileSystemError.Unavailable(err.message); default: throw new FileSystemError(err.message, err.name as files.FileSystemProviderErrorCode); } </ins> } }

Discussion:
<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help
Change:
// settings <del> export const enum EditMode { Live = 'live', Preview = 'preview' } </del> Registry.as<IConfigurationMigrationRegistry>(ExtensionsMigration.ConfigurationMigration).registerConfigurationMigrations( [{

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. --Related For migrating towards ESM in VSCode, it seems the tsconfig option could be useful, ensuring that imports are compatible with ESM. For example, this typescript code transpiled to javascript would cause a runtime error because of the export: The rule would enforce a type only import for : Enabling the tsconfig option in VSCode, it seems these files would need to adjusted:
We reverted this because we learnt, albeit very late, that it has disabled inlining of const enums. See