jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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.75.0-insider OS Version: Windows 11 (21H2, .1455) Steps to Reproduce: editor with CSS/SCSS syntax CSS block e.g. to use Emmet CSS completion with abbreviation of more than 1 character that no Emmet completions are provided Emmet completions seem to only be provided for single-character abbreviations: ! For multi-character abbreviations, I am not getting any results from Emmet at all: ! A of the issue suggests that it was introduced in commit as part of More testing shows some weird behaviour when providing completions, with them showing sometimes but not always when expected: Type - text is - Emmet suggests Type - text is - no suggestions Type - text is - no suggestions Type - text is - Emmet suggests Backspace - text is - Emmet suggests Backspace - text is - Emmet suggests

Related discussion:
text: }); } <del> return new vscode.CompletionList(newItems); </del> <ins> return new vscode.CompletionList(newItems, true); </ins> }); } }
Code change:
off the hot exit and auto save settings an interactive window, run a cell vscode :bug: confirmation pop-up to save the IW

Related discussion:
text: import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { ICellDto2, INotebookEditorModel, INotebookLoadOptions, IResolvedNotebookEditorModel, NotebookCellsChangeType, NotebookData } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <ins> import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> import { IFileWorkingCopyManager } from 'vs/workbench/services/workingCopy/common/fileWorkingCopyManager'; import { IStoredFileWorkingCopy, IStoredFileWorkingCopyModel, IStoredFileWorkingCopyModelContentChangedEvent, IStoredFileWorkingCopyModelFactory, IStoredFileWorkingCopySaveEvent, StoredFileWorkingCopyState } from 'vs/workbench/services/workingCopy/common/storedFileWorkingCopy'; import { IUntitledFileWorkingCopy, IUntitledFileWorkingCopyModel, IUntitledFileWorkingCopyModelContentChangedEvent, IUntitledFileWorkingCopyModelFactory } from 'vs/workbench/services/workingCopy/common/untitledFileWorkingCopy';
Code change:
off the hot exit and auto save settings an interactive window, run a cell vscode :bug: confirmation pop-up to save the IW

Related discussion:
text: private readonly _hasAssociatedFilePath: boolean, readonly viewType: string, private readonly _workingCopyManager: IFileWorkingCopyManager<NotebookFileWorkingCopyModel, NotebookFileWorkingCopyModel>, <del> @IFileService private readonly _fileService: IFileService </del> <ins> @IFileService private readonly _fileService: IFileService, @ILifecycleService lifecycleService: ILifecycleService </ins> ) { super(); <ins> if (this.viewType === 'interactive') { lifecycleService.onBeforeShutdown(async e => e.veto(this.onBeforeShutdown(), 'veto.InteractiveWindow')); } } private async onBeforeShutdown() { if (this._workingCopy?.isDirty()) { await this._workingCopy.save(); } return false; </ins> } override dispose(): void {
Code change:
In virtual workspaces, the file dialog has a button. There's no such dialog in remote windows--the file dialog always shows the remote filesystem. This is an issue for continuing from a GitHub codespace to a local desktop clone when the user is in VS Code desktop. Suggestion: when in a virtual or remote window on desktop, always have the 'Show Local' option in the file dialog.
Oh interesting--there is a Show Local in the Open Folder flow, but not when the git extension invokes the file dialog: <img width="671" alt="image" src="https://user-"
I see this was an intentional decision for extension access to the simple file dialog in a remote window in for However that makes it hard to go from a remote window to a local one from extension land. Is this something that we can expose to extensions via a new proposed api option for the file dialog?
Duplicate of , which is an API request to expose "show local".
Reopening this to track adoption of in the Continue On flow.
Steps: Open a codespace in VS Code desktop From the remote indicator, choose Continue in Local Clone Ensure that the repo gets cloned successfully to your local machine

Related discussion:
text: if (uri !== undefined) { // Launch desktop client if currently in web <ins> let target = `${env.uriScheme}://vscode.git/clone?url=${encodeURIComponent(uri)}`; </ins> if (env.uiKind === UIKind.Web) { <del> let target = `${env.uriScheme}://vscode.git/clone?url=${encodeURIComponent(uri)}`; </del> if (ref !== undefined) { target += `&ref=${encodeURIComponent(ref)}`; } return Uri.parse(target); } <del> // If already in desktop client, directly clone </del> <ins> // If already in desktop client but in a remote window, we need to force a new window // so that the git extension can access the local filesystem for cloning if (env.remoteName !== undefined) { target += `&windowId=_blank`; return Uri.parse(target); } // Otherwise, directly clone </ins> void this.clone(uri, undefined, { ref: ref }); } }
Code change:
Bug The the following entry in its : This seems to cause the python extension to be activated whenever a json file is opened, even though the extension does not provide any json language support This was possibly caused by the move to automatic activation events
I think my initial implementation of implicit activation was perhaps too naive. There seem to be a few issues: It's possible to have a language configuration extension that doesn't contribute any code, and we would now attempt to activate such an extension (this is a noop if there is no main/browser entrypoint in , but results in unnecessary activation if all that's required is a language configuration) the bigger issue is that an extension which contributes extensions, filenames, filenamePatterns, firstLine, or mimeTypes for a language will now get activated anytime the language appears I think it's maybe reasonable to preserve the existing implicit activation behavior if an alias is defined for all of the others, we shouldn't infer , or we should perhaps keep track of the filenames/filenamePatterns etc and activate the extension with the language contribution matching the specified pattern? I know of at least two extensions which are impacted by the current behavior MakeCode Python
:+1: This makes good sense to me. We will infer only for the one which is the "main" language definition, and the best evidence of that is the alias property. I wouldn't do anything beyond that (i.e. tracking filenames, patterns, etc.)
Would the presence of the property be better evidence of a contribution being the main language definition?
injection based syntax highlighting can still have a configuration file

Related discussion:
text: const languageContributions = findNodeAtLocation(tree, ['contributes', 'languages']); languageContributions?.children?.forEach(child => { const id = findNodeAtLocation(child, ['id']); <del> if (id && id.type === 'string') { </del> <ins> const configuration = findNodeAtLocation(child, ['configuration']); if (id && id.type === 'string' && configuration && configuration.type === 'string') { </ins> activationEvents.add(`onLanguage:${id.value}`); } });
Code change:
Bug The the following entry in its : This seems to cause the python extension to be activated whenever a json file is opened, even though the extension does not provide any json language support This was possibly caused by the move to automatic activation events
I think my initial implementation of implicit activation was perhaps too naive. There seem to be a few issues: It's possible to have a language configuration extension that doesn't contribute any code, and we would now attempt to activate such an extension (this is a noop if there is no main/browser entrypoint in , but results in unnecessary activation if all that's required is a language configuration) the bigger issue is that an extension which contributes extensions, filenames, filenamePatterns, firstLine, or mimeTypes for a language will now get activated anytime the language appears I think it's maybe reasonable to preserve the existing implicit activation behavior if an alias is defined for all of the others, we shouldn't infer , or we should perhaps keep track of the filenames/filenamePatterns etc and activate the extension with the language contribution matching the specified pattern? I know of at least two extensions which are impacted by the current behavior MakeCode Python
:+1: This makes good sense to me. We will infer only for the one which is the "main" language definition, and the best evidence of that is the alias property. I wouldn't do anything beyond that (i.e. tracking filenames, patterns, etc.)
Would the presence of the property be better evidence of a contribution being the main language definition?
injection based syntax highlighting can still have a configuration file

Related discussion:
text: }, activationEventsGenerator: (languageContributions, result) => { for (const languageContribution of languageContributions) { <del> if (languageContribution.id) { </del> <ins> if (languageContribution.id && languageContribution.configuration) { </ins> result.push(`onLanguage:${languageContribution.id}`); } }
Code change:
This is a legit error about a bad URI that came from a debug adapter but I guess we shouldn't send telemetry

Related discussion:
text: if (typeof raw.sourceReference === 'number' && raw.sourceReference > 0) { return URI.from({ scheme: DEBUG_SCHEME, <del> path, </del> <ins> path: path?.replace(/^/+/g, '/'), // #174054 </ins> query: `session=${sessionId}&ref=${raw.sourceReference}` }); }
Code change:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

Related discussion:
text: const newWithProfile = nls.localize('newWithProfile', 'The Create New Terminal (With Profile) ({0}) command allows for easy terminal creation using a specific profile.'); const newWithProfileNoKb = nls.localize('newWithProfileNoKb', 'The Create New Terminal (With Profile) command allows for easy terminal creation using a specific profile and is currently not triggerable by a keybinding.'); const accessibilitySettings = nls.localize('accessibilitySettings', 'Access accessibility settings such as `terminal.integrated.tabFocusMode` via the Preferences: Open Accessibility Settings command.'); <ins> const commandPrompt = nls.localize('commandPromptMigration', "Consider using powershell instead of command prompt for an improved experience"); </ins> class AccessibilityHelpWidget extends Widget implements ITerminalWidget { readonly id = 'help'; private _container: HTMLElement | undefined;
Code change:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

Related discussion:
text: private readonly _markdownRenderer: MarkdownRenderer; constructor( <del> instance: ITerminalInstance, </del> <ins> private readonly _instance: ITerminalInstance, </ins> @IKeybindingService private readonly _keybindingService: IKeybindingService, @IInstantiationService instantiationService: IInstantiationService, @IOpenerService private readonly _openerService: IOpenerService ) { super(); <del> this._hasShellIntegration = instance.xterm?.shellIntegration.status === ShellIntegrationStatus.VSCode; </del> <ins> this._hasShellIntegration = _instance.xterm?.shellIntegration.status === ShellIntegrationStatus.VSCode; </ins> this._domNode = createFastDomNode(document.createElement('div')); this._contentDomNode = createFastDomNode(document.createElement('div')); this._contentDomNode.setClassName('terminal-accessibility-help');
Code change:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

Related discussion:
text: this._register(dom.addStandardDisposableListener(this._contentDomNode.domNode, 'keydown', (e) => { if (e.keyCode === KeyCode.Escape) { this.hide(); <del> instance.focus(); </del> <ins> _instance.focus(); </ins> } })); <del> this._register(instance.onDidFocus(() => this.hide())); </del> <ins> this._register(_instance.onDidFocus(() => this.hide())); </ins> this._markdownRenderer = this._register(instantiationService.createInstance(MarkdownRenderer, {})); }
Code change:
Shell integration offers many improvements to the terminal experience and makes it more accessible via commands like . reported that he and many others use which does not have shell integration. Should we include a hint in the help menu that the experience could be better when we detect a screen reader & ?
I think this will improve the discoverability! Voting for this idea.
On windows, Create a terminal - via for example. run . Verify that you see a message about migrating to use powershell.

Related discussion:
text: private _buildContent(): void { const content = []; content.push(this._descriptionForCommand(TerminalCommandId.FocusAccessibleBuffer, focusAccessibleBufferNls, focusAccessibleBufferNoKb)); <ins> if (this._instance.shellType === WindowsShellType.CommandPrompt) { content.push(commandPrompt); } </ins> if (this._hasShellIntegration) { content.push(shellIntegration); content.push('- ' + this._descriptionForCommand(TerminalCommandId.RunRecentCommand, runRecentCommand, runRecentCommandNoKb) + 'n- ' + this._descriptionForCommand(TerminalCommandId.GoToRecentDirectory, goToRecent, goToRecentNoKb));
Code change:
In our menu, we should mention setting
I actually think we should more broadly mention how to find accessibility settings here -

Related discussion:
text: const dismiss = nls.localize('dismiss', "You can dismiss this dialog by pressing Escape or focusing elsewhere."); const openDetectedLink = nls.localize('openDetectedLink', 'The Open Detected Link ({0}) command enables screen readers to easily open links found in the terminal.'); const openDetectedLinkNoKb = nls.localize('openDetectedLinkNoKb', 'The Open Detected Link command enables screen readers to easily open links found in the terminal and is currently not triggerable by a keybinding.'); <ins> const newWithProfile = nls.localize('newWithProfile', 'The Create New Terminal (With Profile) ({0}) command allows for easy terminal creation using a specific profile.'); const newWithProfileNoKb = nls.localize('newWithProfileNoKb', 'The Create New Terminal (With Profile) command command allows for easy terminal creation using a specific profile and is currently not triggerable by a keybinding.'); const accessibilitySettings = nls.localize('accessibilitySettings', 'Access accessibility settings such as `terminal.integrated.tabFocusMode` via the Preferences: Open Accessibility Settings command.'); </ins> class AccessibilityHelpWidget extends Widget implements ITerminalWidget { readonly id = 'help';
Code change:
In our menu, we should mention setting
I actually think we should more broadly mention how to find accessibility settings here -

Related discussion:
text: content.push('- ' + this._descriptionForCommand(TerminalCommandId.RunRecentCommand, runRecentCommand, runRecentCommandNoKb) + 'n- ' + this._descriptionForCommand(TerminalCommandId.GoToRecentDirectory, goToRecent, goToRecentNoKb)); } content.push(this._descriptionForCommand(TerminalCommandId.OpenDetectedLink, openDetectedLink, openDetectedLinkNoKb)); <ins> content.push(this._descriptionForCommand(TerminalCommandId.NewWithProfile, newWithProfile, newWithProfileNoKb)); content.push(accessibilitySettings); </ins> content.push(readMoreLink, dismiss); const element = renderElementAsMarkdown(this._markdownRenderer, this._openerService, content.join('nn'), this._register(new DisposableStore())); const anchorElements = element.querySelectorAll('a');
Code change:
It should be outside of the output region <img width="962" alt="image" src="https://user-"

Related discussion:
text: .traceback.wordWrap span { white-space: pre-wrap; } <del> .output > .scrollable { </del> <ins> .output .scrollable { </ins> overflow-y: scroll; max-height: var(--notebook-cell-output-max-height); border: var(--vscode-editorWidget-border);
Code change:
It should be outside of the output region <img width="962" alt="image" src="https://user-"

Related discussion:
text: } function scrollableArrayOfString(id: string, buffer: string[], container: HTMLElement, trustHtml: boolean) { <del> container.classList.add('scrollable'); </del> <ins> const scrollableDiv = document.createElement('div'); scrollableDiv.classList.add('scrollable'); </ins> if (buffer.length > 5000) { container.appendChild(generateViewMoreElement(id, false)); } <del> const div = document.createElement('div'); container.appendChild(div); div.appendChild(handleANSIOutput(buffer.slice(0, 5000).join('n'), trustHtml)); </del> <ins> container.appendChild(scrollableDiv); scrollableDiv.appendChild(handleANSIOutput(buffer.slice(0, 5000).join('n'), trustHtml)); </ins> } export function insertOutput(id: string, outputs: string[], linesLimit: number, scrollable: boolean, container: HTMLElement, trustHtml: boolean) {
Code change:
Testing have search view open drag the explorer icon onto it the explorer (and npm script) views show the explorer icon stays in the activity bar, the view is empty https://user-

Related discussion:
text: storageId: 'workbench.explorer.views.state', icon: explorerViewIcon, alwaysUseContainerInfo: true, <ins> hideIfEmpty: true, </ins> order: 0, openCommandActionDescriptor: { id: VIEWLET_ID,
Code change:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

Related discussion:
text: private _tabFocusTerminal: boolean = false; private _tabFocusEditor: boolean = false; <del> private readonly _onDidChangeTabFocus = new Emitter<boolean>(); public readonly onDidChangeTabFocus: Event<boolean> = this._onDidChangeTabFocus.event; </del> <ins> private readonly _onDidChangeTabFocus = new Emitter<void>(); public readonly onDidChangeTabFocus: Event<void> = this._onDidChangeTabFocus.event; </ins> public getTabFocusMode(context: TabFocusContext): boolean { return context === TabFocusContext.Terminal ? this._tabFocusTerminal : this._tabFocusEditor; } public setTabFocusMode(tabFocusMode: boolean, context: TabFocusContext): void { <del> if ((context === TabFocusContext.Terminal && this._tabFocusTerminal === tabFocusMode) || (context === TabFocusContext.Editor && this._tabFocusEditor === tabFocusMode)) { return; } </del> if (context === TabFocusContext.Terminal) { this._tabFocusTerminal = tabFocusMode; } else { this._tabFocusEditor = tabFocusMode; } <del> this._onDidChangeTabFocus.fire(this._tabFocusTerminal); </del> <ins> this._onDidChangeTabFocus.fire(); </ins> } }
Code change:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

Related discussion:
text: private readonly languageElement = this._register(new MutableDisposable<IStatusbarEntryAccessor>()); private readonly metadataElement = this._register(new MutableDisposable<IStatusbarEntryAccessor>()); private readonly currentProblemStatus: ShowCurrentMarkerInStatusbarContribution = this._register(this.instantiationService.createInstance(ShowCurrentMarkerInStatusbarContribution)); <ins> private _previousViewContext: 'terminal' | 'editor' | undefined; </ins> private readonly state = new State(); private readonly activeEditorListeners = this._register(new DisposableStore()); private readonly delayedRender = this._register(new MutableDisposable());
Code change:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

Related discussion:
text: this._register(this.textFileService.untitled.onDidChangeEncoding(model => this.onResourceEncodingChange(model.resource))); this._register(this.textFileService.files.onDidChangeEncoding(model => this.onResourceEncodingChange((model.resource)))); this._register(Event.runAndSubscribe(TabFocus.onDidChangeTabFocus, () => this.onTabFocusModeChange())); <ins> const viewKey = new Set<string>(); viewKey.add('focusedView'); this._register(this.contextKeyService.onDidChangeContext((c) => { if (c.affectsSome(viewKey)) { const terminalFocus = this.contextKeyService.getContextKeyValue('focusedView') === 'terminal'; const context = terminalFocus ? 'terminal' : 'editor'; if (this._previousViewContext === context) { return; } this._previousViewContext = context; this.onTabFocusModeChange(); } })); </ins> } private registerCommands(): void {