jiebi/CodeConvo huggingface dataset:
Code change:
override updateOptions(options: IWorkbenchListOptionsUpdate): void { super.updateOptions(options); <del> this.updateStyles(options.overrideStyles); </del> <ins> if (options.overrideStyles !== undefined) { this.updateStyles(options.overrideStyles); } </ins> if (options.multipleSelectionSupport !== undefined) { this.listSupportsMultiSelect.set(!!options.multipleSelectionSupport);

Related discussion:
text: I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Code change:
markdownDescription: localize('terminal.integrated.accessibleViewPreserveCursorPosition', "Preserve the cursor position on reopen of the terminal's accessible view rather than setting it to the bottom of the buffer."), type: 'boolean', default: false <del> } </del> <ins> }, [TerminalSettingId.AccessibleViewFocusOnCommandExecution]: { markdownDescription: localize('terminal.integrated.accessibleViewFocusOnCommandExecution', "Focus the terminal accessible view when a command is executed."), type: 'boolean', default: false }, </ins> } };

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:
import { IQuickPickSeparator } from 'vs/platform/quickinput/common/quickInput'; import { IViewsService } from 'vs/workbench/common/views'; import { DEBUG_CONSOLE_QUICK_ACCESS_PREFIX, SELECT_AND_START_ID } from 'vs/workbench/contrib/debug/browser/debugCommands'; <del> import { getStateLabel, IDebugService, IDebugSession, REPL_VIEW_ID } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDebugService, IDebugSession, REPL_VIEW_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> export class DebugConsoleQuickAccess extends PickerQuickAccessProvider<IPickerQuickAccessItem> {

Related discussion:
text: Testing !
I just noticed that is not localized and is not meant for display. That means that "Label" was not a good name for that function, but we can either just remove the state or find the code that drives the state label in the callstack.
Actually, it seems that only displays , , or , which is probably not super useful to the user anyways. It seems like the info like is only available on each thread, and a debug session can have multiple threads. Perhaps we should just remove the state for now.
Code change:
}; } <del> function slugFromHeading(heading: string): string { </del> <ins> function addLinkRenderer(md: MarkdownIt): void { const original = md.renderer.rules.link_open; md.renderer.rules.link_open = (tokens: MarkdownItToken[], idx: number, options, env, self) => { const token = tokens[idx]; const href = token.attrGet('href'); if (typeof href === 'string' && href.startsWith('#')) { token.attrSet('href', '#' + slugify(href.slice(1))); } if (original) { return original(tokens, idx, options, env, self); } else { return self.renderToken(tokens, idx, options); } }; } function slugify(text: string): string { </ins> const slugifiedHeading = encodeURI( <del> heading.trim() </del> <ins> text.trim() </ins> .toLowerCase() .replace(/s+/g, '-') // Replace whitespace with - // allow-any-unicode-next-line

Related discussion:
text: [X] Notebooks (.ipynb files) [ ] Interactive Window and/or Cell Scripts (.py files with #%% markers) Hello. As the title says, I can't make a internal link in a jupyter notebook in vscode if the cell's title starts with a capital letter, contains an underscore or contains a space, as you can see on the images. Also, on the sole option that it works, non-capital letter header, when clicked it brings me to the bottom of the notebook, and the focus is not brought on the right header itself. Initial tests: ! The test headers: ! 64.5 v2022.2. Python v3.8.5 Python Extension: v2022.2. No response Local
This is actually handled by VS code core (and not the extension). I've included a demo notebook that repros the problem .
In the demo notebook, the href jumps all work ! But none of the header jumps do unless you rewrite them to be only lowercase. All of the links work fine when running in 'jupyter'.
Vscode this notebook is still with all the bugs. Even on the links that work, they jump me to the very bottom of the notebook, not to cell 2, cell 3 or cell 4. Also Section jump and Section with space jump still doesn't work at all. I'm using portable Vscode btw, but I think this doesn't make any difference since when I was using the regular one this bug still existed. Even now, about 2 years later (that I recall) it still goes on on notebooks in Vscode. I can record a GIF if you need. I assure no weird magic was done on my vscode, just regular installation and all... and I can confirm that this issue still occurred years ago on my other PC too.
Does this reproduce in the ?
It did for me.
Will this issue be addressed on any new version of Vscode? I've headed to version 1.67 and to "April+2022+Recovery+2"+is%3Aclosed and found no mentions of this issue. Perhaps on the next, if it would be implemented/fixed at all? Thanks anyway! :)
This issue was fixed in 1.68 (the May 2022 milestone)
got a look at and pull request ( ) doesn't appear there.
Code change:
}; } <del> function slugFromHeading(heading: string): string { </del> <ins> function addLinkRenderer(md: MarkdownIt): void { const original = md.renderer.rules.link_open; md.renderer.rules.link_open = (tokens: MarkdownItToken[], idx: number, options, env, self) => { const token = tokens[idx]; const href = token.attrGet('href'); if (typeof href === 'string' && href.startsWith('#')) { token.attrSet('href', '#' + slugify(href.slice(1))); } if (original) { return original(tokens, idx, options, env, self); } else { return self.renderToken(tokens, idx, options); } }; } function slugify(text: string): string { </ins> const slugifiedHeading = encodeURI( <del> heading.trim() </del> <ins> text.trim() </ins> .toLowerCase() .replace(/s+/g, '-') // Replace whitespace with - // allow-any-unicode-next-line

Related discussion:
text: Will it be ? Thanks :)
Did you test it?
Yes! everything was fixed. Capital letters, underscore and space headers now work like a charm. I was just asking if this specific commit ( ) will be listed on the update website. I don't know how it works, if minor fixes won't get listed or something like that. I just wanted to show to some friends that somehow I've contributed to Vscode with my bug report Anyway, everything buggy was fixed. This issue may be closed anytime.
Code change:
); } <del> async cloneRepository(url?: string, parentPath?: string, options: { recursive?: boolean } = {}): Promise<void> { </del> <ins> async cloneRepository(url?: string, parentPath?: string, options: { recursive?: boolean; ref?: string } = {}): Promise<void> { </ins> if (!url || typeof url !== 'string') { url = await pickRemoteSource({ providerLabel: provider => localize('clonefrom', "Clone from {0}", provider.name),

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. --vscode- a directory to clone your repo into cloned repo :bug: branch context is not preserved This impacts Continue Working On--branch context is preserved for Clone in Container and Create New Codespace. I propose adding a new optional query parameter to the uri handler here: and passing that to the command as an optional argument here Then after cloning here: and before opening the repo in a new window, we would perform the ref checkout:
will you create a test plan item/verification steps for this feature?
yes I will!
Code change:
const NOTEBOOK_FIND_IN_CODE_INPUT = nls.localize('notebook.find.filter.findInCodeInput', "Code Cell Source"); const NOTEBOOK_FIND_IN_CODE_OUTPUT = nls.localize('notebook.find.filter.findInCodeOutput', "Code Cell Output"); <del> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 318; </del> <ins> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 419; </ins> const NOTEBOOK_FIND_WIDGET_INITIAL_HORIZONTAL_PADDING = 4; class NotebookFindFilterActionViewItem extends DropdownMenuActionViewItem { constructor(readonly filters: NotebookFindFilters, action: IAction, options: IActionViewItemOptions, actionRunner: IActionRunner, @IContextMenuService contextMenuService: IContextMenuService) {

Related discussion:
text: Testing I found "Find in Cell Selection" confusing label for the button given it is to find in selected cells. Does it make sense? Would "Find in Selected Cells" be a bit easier? !
Yeah, agreed that the labeling isn't perfect. Will workshop this in the next iteration, as this button will be serving dual purpose as a way to search in textual selections within a cell, as well as searching in multi-cell selections as the feature is currently. Thanks for the feedback!
Code change:
const NOTEBOOK_FIND_IN_CODE_INPUT = nls.localize('notebook.find.filter.findInCodeInput', "Code Cell Source"); const NOTEBOOK_FIND_IN_CODE_OUTPUT = nls.localize('notebook.find.filter.findInCodeOutput', "Code Cell Output"); <del> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 318; </del> <ins> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 419; </ins> const NOTEBOOK_FIND_WIDGET_INITIAL_HORIZONTAL_PADDING = 4; class NotebookFindFilterActionViewItem extends DropdownMenuActionViewItem { constructor(readonly filters: NotebookFindFilters, action: IAction, options: IActionViewItemOptions, actionRunner: IActionRunner, @IContextMenuService contextMenuService: IContextMenuService) {

Related discussion:
text: Notebooks: ! Editor: ! Version: 1.90.0-insider Commit: Date: 2024-05-28T05:48:32.492Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Darwin arm64 23.4.0
Code change:
const NOTEBOOK_FIND_IN_CODE_INPUT = nls.localize('notebook.find.filter.findInCodeInput', "Code Cell Source"); const NOTEBOOK_FIND_IN_CODE_OUTPUT = nls.localize('notebook.find.filter.findInCodeOutput', "Code Cell Output"); <del> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 318; </del> <ins> const NOTEBOOK_FIND_WIDGET_INITIAL_WIDTH = 419; </ins> const NOTEBOOK_FIND_WIDGET_INITIAL_HORIZONTAL_PADDING = 4; class NotebookFindFilterActionViewItem extends DropdownMenuActionViewItem { constructor(readonly filters: NotebookFindFilters, action: IAction, options: IActionViewItemOptions, actionRunner: IActionRunner, @IContextMenuService contextMenuService: IContextMenuService) {

Related discussion:
text: Type: <bBug</bThe default width feels small, especially that we have 4 icons in the notebook find widget. It can only render 6 characters and then truncate. ! VS Code version: Code - Insiders 1.88.0-insider (, 2024-03-28T22:10:25.599Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (27)</summaryExtensionVersion ------ esbuild-problem-matchers0.0.3 vscode-eslint2.4.4 vscode-deno3.36.0 gitlens2024.3.2805 EditorConfig0.16.4 prettier-vscode10.4.0 copilot1.176.0 copilot-chat0.14. vscode-pull-request-github0.85. vscode-mocha-test-adapter2.14.1 vscode-test-explorer2.21.1 vscode-dotnet-runtime2.0.3 black-formatter2024.1. debugpy2024.2.0 isort2023.10.1 python2024.3. vscode-pylance2024.3.102 datawrangler0.29.6 jupyter2024.3. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.353.0 extension-test-runner0.0.6 test-adapter-converter0.1.9 vscode-github-issue-notebooks0.0.130 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Code change:
export const USER_DATA_SYNC_SCHEME = 'vscode-userdata-sync'; export const PREVIEW_DIR_NAME = 'preview'; <ins> export const EXTENSIONS_SYNC_CONTEXT_KEY = 'extensionsSync'; </ins>

Related discussion:
text: I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).
Code change:
} } <del> function getReportIssueArgsForError(error: TypeScriptServerError): { issueTitle: string, issueBody: string } | undefined { </del> <ins> function getReportIssueArgsForError(error: TypeScriptServerError): { extensionId: string, issueTitle: string, issueBody: string } | undefined { </ins> if (!error.serverStack || !error.serverMessage) { return undefined; }

Related discussion:
text: Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Code change:
async updateLocalExtensions(added: ISyncExtension[], removed: IExtensionIdentifier[], updated: ISyncExtension[], skippedExtensions: ISyncExtension[], profile: IUserDataProfile): Promise<ISyncExtension[]> { const syncResourceLogLabel = getSyncResourceLogLabel(SyncResource.Extensions, profile); <del> return this.withProfileScopedServices(profile, async (extensionEnablementService, extensionStorageService) => { const removeFromSkipped: IExtensionIdentifier[] = []; const addToSkipped: ISyncExtension[] = []; const installedExtensions = await this.extensionManagementService.getInstalled(undefined, profile.extensionsResource); if (removed.length) { const extensionsToRemove = installedExtensions.filter(({ identifier, isBuiltin }) => !isBuiltin && removed.some(r => areSameExtensions(identifier, r))); await Promises.settled(extensionsToRemove.map(async extensionToRemove => { this.logService.trace(`${syncResourceLogLabel}: Uninstalling local extension...`, extensionToRemove.identifier.id); await this.extensionManagementService.uninstall(extensionToRemove, { donotIncludePack: true, donotCheckDependents: true, profileLocation: profile.extensionsResource }); this.logService.info(`${syncResourceLogLabel}: Uninstalled local extension.`, extensionToRemove.identifier.id); removeFromSkipped.push(extensionToRemove.identifier); })); } </del> <ins> const extensionsToInstall: [ISyncExtension, IGalleryExtension][] = []; const removeFromSkipped: IExtensionIdentifier[] = []; const addToSkipped: ISyncExtension[] = []; const installedExtensions = await this.extensionManagementService.getInstalled(undefined, profile.extensionsResource); </ins> <del> if (added.length || updated.length) { </del> <ins> // 1. Sync extensions state first so that the storage is flushed and updated in all opened windows if (added.length || updated.length) { await this.withProfileScopedServices(profile, async (extensionEnablementService, extensionStorageService) => { </ins> await Promises.settled([...added, ...updated].map(async e => { const installedExtension = installedExtensions.find(installed => areSameExtensions(installed.identifier, e.identifier));

Related discussion:
text: I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).
Code change:
id: 'editor.action.toggleScreenReaderAccessibilityMode', title: { value: nls.localize('toggleScreenReaderMode', "Toggle Screen Reader Accessibility Mode"), original: 'Toggle Screen Reader Accessibility Mode' }, f1: true, <ins> keybinding: { primary: KeyMod.CtrlCmd | KeyCode.KeyE, weight: KeybindingWeight.WorkbenchContrib + 10, when: accessibilityHelpIsShown } </ins> }); }

Related discussion:
text: It doesn't matter in this case, but note that you collect all the keyListener disposables in the store of the AccessibleView class (even if you dispose them in , but the disposable is still in the disposableStore). This can lead to memory leaks. I can really recommend to compose components according to their life times. I think here the lifetime of the rendered content is owned by the caller of (the caller is supposed to call on the result). So the disposable returned by should be owned by whatever you return in . I suggest to create a DisposableStore in render, push the key listener to it once the text model resolves and return the disposable store at the end of render (also add the to the store). Also, note that the getTextModel promise can resolve after the caller called dispose. Originally posted by in
Code change:
override async revealRangeInCenterIfOutsideViewportAsync() { } override async layoutNotebookCell() { } override async removeInset() { } <del> override async focusNotebookCell() { } </del> <ins> override async focusNotebookCell(cell: ICellViewModel, focusItem: 'editor' | 'container' | 'output') { cell.focusMode = focusItem === 'editor' ? CellFocusMode.Editor : focusItem === 'output' ? CellFocusMode.Output : CellFocusMode.Container; } </ins> override cellAt(index: number) { return viewModel.cellAt(index)!; } override getCellIndex(cell: ICellViewModel) { return viewModel.getCellIndex(cell); } override getCellsInRange(range?: ICellRange) { return viewModel.getCellsInRange(range); }

Related discussion:
text: Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.
Code change:
return TerminalInstance._lastKnownCanvasDimensions; } <del> set shutdownPersistentProcessId(shutdownPersistentProcessId: number | undefined) { this._shutdownPersistentProcessId = shutdownPersistentProcessId; } get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId ?? this._shutdownPersistentProcessId; } get shouldPersist(): boolean { return (this._processManager.shouldPersist || this._shutdownPersistentProcessId !== undefined) && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </del> <ins> get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId; } get shouldPersist(): boolean { return this._processManager.shouldPersist && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </ins> /** * Create xterm.js instance and attach data listeners.

Related discussion:
text: Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.