jiebi/CodeConvo huggingface dataset:
Code change:
this._fixedRows = _shellLaunchConfig.attachPersistentProcess?.fixedDimensions?.rows; this._fixedCols = _shellLaunchConfig.attachPersistentProcess?.fixedDimensions?.cols; <ins> this._icon = _shellLaunchConfig.attachPersistentProcess?.icon || _shellLaunchConfig.icon; </ins> // the resource is already set when it's been moved from another window this._resource = resource || getTerminalUri(this._workspaceContextService.getWorkspace().id, this.instanceId, this.title);

Related discussion:
text: Hi, I would like to request that upon restart vscode, the terminals can be restored. By restored, i mean the layout, the custom names, icon and color for the terminals are retained. The content DOES NOT need to be retain. Otherwise efforts to customize all the opened terminals would gone to waste when vscode is restarted. Alternatively, vscode can provide new workspace configurations, where developer can manually enter a list of terminals' custom names, Vscode, upon starting, will automatically create new terminals based on the configured list. Even better, each time, deveoper manually open a new terminal , vscode will auto update the workspace configuration file to add a new terminal to the configured list. This applies the same to renaming of terminal Hope that this can be achieved without relying on plugin. *Do note that this might not be a duplicate of other look similar kind of feature request. Cos for this request, content does not need to be preserved. And the terminal's custom names should be preserved (sadly, persistentSessionReviveProcess, does not maintain the terminal custom names)
except it doesn't save custom terminal names.
Not only it doesn't save custom terminal names, it also doesn't save icon and color.
This is meant to be supported with including content as well, there are currently some issues with it causing it to be flaky though. They might have to wait until v1.63 where we will focus on testing. Related:
fixed !
It's persisting the icon, color, name, and layout on window reload. Doesn't seem to persist icon, color, or name on restart.
Yes. My request is focusing on restart, not window reload
Code change:
const merge = require('merge-options'); const CopyWebpackPlugin = require('copy-webpack-plugin'); const { NLSBundlePlugin } = require('vscode-nls-dev/lib/webpack-bundler'); <del> const { DefinePlugin } = require('webpack'); </del> <ins> const { DefinePlugin, optimize } = require('webpack'); </ins> function withNodeDefaults(/**@type WebpackConfig*/extConfig) { /** @type WebpackConfig */

Related discussion:
text: developer tools console :bug: see a bunch of errors like this for github authentication, microsoft authentication, typescript language features, remote repositories etc
Code change:
import { IEditorGroupService } from 'vs/workbench/services/group/common/groupService'; import { IMessageService } from 'vs/platform/message/common/message'; import { IWorkspaceConfigurationService } from 'vs/workbench/services/configuration/common/configuration'; <del> import { IWindowsService, IWindowService } from 'vs/platform/windows/common/windows'; </del> <ins> import { IWindowsService, IWindowService, IWindowSettings } from 'vs/platform/windows/common/windows'; </ins> import { IContextMenuService } from 'vs/platform/contextview/browser/contextView'; import { IWindowIPCService } from 'vs/workbench/services/window/electron-browser/windowService'; import { IWorkspaceContextService } from 'vs/platform/workspace/common/workspace';

Related discussion:
text: VSCode Version: 1.8.0 OS Version: Windows Version 6.3.9600 (Windows 8.1 Enterprise) Steps to Reproduce: High Contrast on Windows VS Code, look at the glorious High Contrast theme a different theme, because you would rather work in that VS Code, your theme choice gets overridden. Essentially, I'd like to be able to disable the auto-detection of the High Contrast theme I'm using in Windows via some setting, because while I prefer Windows in High Contrast mode, I dislike looking at VS Code's High Contrast theme.
I wholeheartedly agree. I'm okay with the default being auto-detection, for the accessibility scenario, but it should definitely be possible to disable this functionality via settings.
An option makes sense to me. If someone wants to provide a PR
Done,
Could you please re-open this issue? Unfortunately, my PR only affected the high-contrast swap that occurred when changing Windows theme while VSCode is open, not the initial theme that is set when VSCode starts, or opens a new folder. I have a new PR that completes the fix.
[x] To verify (Windows): Normally VS Code switches to HC mode automatically when windows is running in HC mode. Verify this new setting can be used to prevent this automatic switch from happening (both on startup as well as when Code is running and you change HC mode in Windows).
Code change:
// rerender them. this.buttonsUpdated = true; } <ins> if (this.toggles.length) { // if there are toggles, the ui.show() clears them out of the UI so we should // rerender them. this.togglesUpdated = true; } </ins> this.update(); }

Related discussion:
text: Type: <bBug</bFuzzy search icon is visible in Go to Symbol view (Shift + CMD + O) which on press opens terminal recent search with fuzzy search. I think that button should be excluded from Go to Symbol view and be visible only in terminal recent search view. VS Code version: Code 1.73.1 (, 2022-11-09T02:22:48.959Z) OS version: Darwin arm64 22.1.0 <img width="607" alt="image" src="https://user-"<img width="597" alt="image" src="https://user-"<!-- generated by issue reporter --
Seems like after the icon is not cleared and shows up in any command palette entry
Code change:
} export function getSecondaryEdits(textModel: ITextModel, positions: readonly Position[], primaryEdit: SingleTextEdit): SingleTextEdit[] { <ins> if (positions.length === 1) { // No secondary cursor positions return []; } </ins> const primaryPosition = positions[0]; const secondaryPositions = positions.slice(1); const primaryEditStartPosition = primaryEdit.range.getStartPosition();

Related discussion:
text: There is a injected text that is left over on line 52: <img width="883" alt="image" src=""Saw this stack-trace, I'm not sure if it's related or not:
I am trying to reproduce this issue but am currently not able to. Do you know what is the file you were triggering inline completions on, and what inline completions you saw ?
Code change:
private _cursorBlinking: TextEditorCursorBlinkingStyle; private _cursorStyle: TextEditorCursorStyle; private _cursorSmoothCaretAnimation: 'off' | 'explicit' | 'on'; <ins> private _experimentalEditContextEnabled: boolean; </ins> private _selectionIsEmpty: boolean; private _isComposingInput: boolean;

Related discussion:
text: Version: 1.94.0-insider Commit: Date: 2024-09-20T05:03:57.400Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: Set Google IME for Japanese. The cursor is not visible during typing. On almost all the platforms and all the applications, the cursor is usually visible during composition.
Hi yes thank you for opening this issue. This is caused by some code that is related to the current edit context implementation which hides the blinking cursor because there is already a blinking cursor in the visible text area shown during composition. A PR has been made to fix this.
Code change:
resource: vscode.Uri, previewSettings: DynamicPreviewSettings ): DynamicMarkdownPreview { <ins> const activeTextEditorURI = vscode.window.activeTextEditor?.document.uri; const scrollLine = (activeTextEditorURI?.toString() === resource.toString()) ? vscode.window.activeTextEditor?.visibleRanges[0].start.line : undefined; </ins> const preview = DynamicMarkdownPreview.create( { resource, resourceColumn: previewSettings.resourceColumn, locked: previewSettings.locked, <ins> line: scrollLine, </ins> }, previewSettings.previewColumn, this._contentProvider,

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. --- VS Code Version: 1.56.1 OS Version: Windows Steps to Reproduce: a (reasonably long) markdown file and scroll down a bit. the dynamic preview for the markdown file. It opens the preview at the top of the file, but should open it where your text editor (containing the target markdown) is scrolled to. This is not adjusted until the user scrolls or resizes the window. <!-- 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. --
Code change:
}); } <del> public acceptNextLine(editor: ICodeEditor): void { this._acceptNext(editor, (pos, text) => { </del> <ins> public async acceptNextLine(editor: ICodeEditor): Promise<void> { await this._acceptNext(editor, (pos, text) => { </ins> const m = text.match(/n/); if (m && m.index !== undefined) { return m.index + 1;

Related discussion:
text: One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- 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. 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!
Code change:
} private toSymbolInformation(item: Proto.NavtoItem): vscode.SymbolInformation | undefined { <del> if (!item.containerName || item.kind === 'alias') { </del> <ins> if (item.kind === 'alias' && !item.containerName) { </ins> return; }

Related discussion:
text: Using the workspace TS version, 5.5.0-dev.: ! ! !
Closing for verification
Code change:
precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), keybinding: [ { <del> primary: KeyMod.Shift | KeyCode.Tab, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow, KeyMod.Alt | KeyCode.F2], </del> <ins> primary: KeyMod.Alt | KeyCode.F2, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow], </ins> weight: KeybindingWeight.WorkbenchContrib, when: ContextKeyExpr.and(CONTEXT_ACCESSIBILITY_MODE_ENABLED, TerminalContextKeys.focus, ContextKeyExpr.or(terminalTabFocusModeContextKey, TerminalContextKeys.accessibleBufferFocus.negate())) }

Related discussion:
text: Type: <bBug</bthe settings like below: : new terminal via ctrl+` from terminal input. Pressing Shift+Tab moves to the terminal buffer. Shift+Tab should be passed to terminal as an input key. The focus needs to remain in the terminal input field. We need when cycling back through shell auto-suggestion or ipython completion. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-19T05:34:51.441Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (90)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.1.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 dscodegpt2.1.14 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.12 copilot1.97.271 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11.
Code change:
precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), keybinding: [ { <del> primary: KeyMod.Shift | KeyCode.Tab, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow, KeyMod.Alt | KeyCode.F2], </del> <ins> primary: KeyMod.Alt | KeyCode.F2, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow], </ins> weight: KeybindingWeight.WorkbenchContrib, when: ContextKeyExpr.and(CONTEXT_ACCESSIBILITY_MODE_ENABLED, TerminalContextKeys.focus, ContextKeyExpr.or(terminalTabFocusModeContextKey, TerminalContextKeys.accessibleBufferFocus.negate())) }

Related discussion:
text: python2023.12.0 vscode-pylance2023.7.30 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.301.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.1717 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5873 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.2 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.20.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.23 latex-utilities0.4.10 chatgpt1.1.2 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
related this also reproduces in stable VS code
We're going to remove the keybinding altogether as it should enter the buffer when toggle tab moves focus is enabled and not (as designed) without that
Changing the keybinding could throw users off,
Code change:
precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), keybinding: [ { <del> primary: KeyMod.Shift | KeyCode.Tab, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow, KeyMod.Alt | KeyCode.F2], </del> <ins> primary: KeyMod.Alt | KeyCode.F2, secondary: [KeyMod.CtrlCmd | KeyCode.UpArrow], </ins> weight: KeybindingWeight.WorkbenchContrib, when: ContextKeyExpr.and(CONTEXT_ACCESSIBILITY_MODE_ENABLED, TerminalContextKeys.focus, ContextKeyExpr.or(terminalTabFocusModeContextKey, TerminalContextKeys.accessibleBufferFocus.negate())) }

Related discussion:
text: though is wondering if we can treat this like a widget with results/ input and allow moving between the two with keybindings consistent with
Shift+tab is still going to the workbench even when I remove that keybinding and have tab moves focus mode off
We now allow using or to go to the terminal accessible buffer instead. I think it makes sense to remove as a keybinding next iteration if we agree that makes sense and The only downside of that would be users might already have in their muscle memory.
If we cannot resolve the synchronization issue with autocomplete and shift +Tab, I am in favor of removing the key-binding. there are worse things than retraining mussel memory.
Yes, and I just discussed, and we agree it can be removed this iteration.
We will also remove the tab index
I cannot reproduce the original issue in stable (either 1.81 or 1.78). What are the steps to verify?
Sorry, to verify, focus a terminal with screen reader mode enabled. Use . the accessible buffer should not open.
This does input and no longer shows the a11y buffer, but the event also bubbles beyond and moves the focus to the panel title incorrectly: !
Guessing we need to do something with tabindex that must've been removed in order to get this to work
I think it would be either shift+tab needs to be specially handled in or we should handle it and cancel the event in the custom key event handler.
not sure how this was working before. I dug through commits and tried reverting this one, which didn't help.
Code change:
import { Event } from 'vs/base/common/event'; const WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 60; // 1 hour <del> const MIN_WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 5; // 5 minutes </del> <ins> const MIN_WAIT_TIME_TO_SHOW_SURVEY = 1000 * 60 * 2; // 2 minutes </ins> const MAX_INSTALL_AGE = 1000 * 60 * 60 * 24; // 24 hours const REMIND_LATER_DELAY = 1000 * 60 * 60 * 4; // 4 hours const SKIP_SURVEY_KEY = 'ces/skipSurvey';

Related discussion:
text: If the knows which languages a user tried in their first day, it could unlock more specific questions to further improve the language onboarding experience. How though. tracks the edited count for languages that run surveys; which are the languages we care most about right now. Only issue is that the storage key isn't exported, so the doesn't know about it. any general thoughts on the idea, and best practices on how to make the storage keys known to the ces survey code; so they can be read and attached as params to the survey URL?
The CES code already has access to the same . Can't you copy the maps the surveys to storage service keys over to CES and read them from there?
Sure, was mainly worried that this creates some copy/pasta. Will take that approach for an initial pull request draft and gather feedback.
No worries. We can also extract the common code to a new file, sibling to those two.
are there verification steps for this?
Sorry that they are so complex and time-intensive. I can also verify that I see survey responses from insiders that include the language data. a fresh VS Code Insiders instance , ensure that you are in the treatment group a Java file and save it. VS Code open for 1 hour to trigger the new-user survey popup and click to open the survey that the URL it opened contains
Ok, see you in an hour!
The treatment service does not seem to like me, for some reason. Unmarking as verified for someone else to give it a shot. Note that you need to repeatedly open VS Code windows with new user-data-dir's until you get into the treatment.
Also attempted this but no survey after an hour. Confirmed I did get an initial
when the experiment enables the survey you should also get a event? Did that work?
Testing again
Worked! [redacted]&javaLang=1
Code change:
let bestDelta = 0; let bestScore = -1; // find best scored delta <del> for (let delta = -deltaBefore; delta < deltaAfter; delta++) { </del> <ins> for (let delta = -deltaBefore; delta <= deltaAfter; delta++) { </ins> const seq2OffsetStart = diff.seq2Range.start + delta; const seq2OffsetEndExclusive = diff.seq2Range.endExclusive + delta; const seq1Offset = diff.seq1Range.start + delta;

Related discussion:
text: Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:
Code change:
const emptyWindowsWithBackupsToRestore: IEmptyWindowBackupInfo[] = []; let filesToOpen: IFilesToOpen | undefined; <del> let emptyToOpen = 0; </del> <ins> let openOneEmptyWindow = false; </ins> // Identify things to open from open config const pathsToOpen = await this.getPathsToOpen(openConfig);

Related discussion:
text: Steps to Reproduce: to 1 window on a folder open the command line run = only the folder opens, but not an empty window I would expect here 2 windows to open, one is the folder and one the empty window since no argument was given to open any folder or file.
Code change:
} hide() { <del> this._isExpanded = false; // Focus the container so that the comment editor will be blurred before it is hidden this.editor.focus(); </del> <ins> if (this._isExpanded) { this._isExpanded = false; // Focus the container so that the comment editor will be blurred before it is hidden this.editor.focus(); } </ins> super.hide(); }

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44.2 OS Version: macOS Steps to Reproduce: an extension providing in-editor comments via the comments API an editor containing comments the terminal at the bottom a command which causes the comments to be updated. For our comment provider, we automatically detect comments associated with your source control commit. So, for example, use the command line to checkout a different commit. comments will change, causing some of the previous comments to be hidden. When this happens, the editor is focused. This causes you to lose focus on the terminal. The end result UX is that you're typing commands in the terminal, and your focus gets stolen to an open editor for no visible reason, making it annoying if you wanted to keep running more commands. Notably, this depends on the way the comments API is used. I believe many comment providers do not respond to source control, and require clicking a button to activate/deactivate, so it's likely that's why this hasn't been reported before. For us, this is really annoying, and I could see this hitting other providers in the future. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No, because you need an extension which contributes via comments API
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.562 --- <!-- score: 0.513 --- <!-- score: 0.501 --- <!-- score: 0.493 --- <!-- score: 0.492 --<!-- potentialduplicatescomment --