jiebi/CodeConvo huggingface dataset:
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0-beta.5.tgz#6992a6f56349e67b903201d52b1ad41ba3469d93" integrity sha512-MaqnU34WTHCUAo7moB4KhynGn03RckI0JJ8E/gXe96EzuCP6bVJIKSc5pc9iFeLF4BX1SuemOqIHYl2Q3u3NTA== <del> xterm-addon-webgl@0.14.0-beta.46: version "0.14.0-beta.46" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.14.0-beta.46.tgz#d25cbdf18f67e45b60782c5abe4accf2ddaf0c0f" integrity sha512-kULKDY2toIjgI8GlM0AEmi8wcBJxhv+b49tBJFYpgTV338gGD5cFfFl4zunOwO7+N0de8G5a5P16MVRjHp5ARg== </del> <ins> xterm-addon-webgl@0.14.0-beta.50: version "0.14.0-beta.50" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.14.0-beta.50.tgz#e52a7fd1776c214163e15fcabedf1f0b51f75445" integrity sha512-UF8+hBYplKxuOK5ZzLBhbC7cFOqTx0vkcK1dw8mmqL0x8v1lwfz2eRxiqokkC4bDVq3CAKlul1IuEF9cQs5sZQ== </ins> <del> xterm@5.1.0-beta.82: version "5.1.0-beta.82" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.1.0-beta.82.tgz#e1e4c7db5547e0b9f8a381ed59c266269363c21e" integrity sha512-/s6ueCDOmgJpLS2P5uttQLvy9Pg9uE+R0G9rnXC2e7bxks0ljnc2V4w2PMd2Iidk4oR4F/4K/rFhCPlX+cVZ3A== </del> <ins> xterm@5.1.0-beta.87: version "5.1.0-beta.87" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.1.0-beta.87.tgz#a4bb442b73e82941f87819f6db7810949536c891" integrity sha512-0cR7TUfAUH6Z1CVzVCm2CnFs7slqro2nf11yjrWvZyxEoGb34rNWvcnvIq2L5Xzv+gvHbl8jDO8yj5nyxQvUCA== </ins>

Discussion:
Testing Code insiders, set how the inactive selection colour is stronger than the active selection colour I can only reproduce this with "canvas", all other gpu acceleration options work fine. Terminal focused ! Terminal not focused !
Upstream:
Change:
nls.localize('explicitSaveBoolean', 'Triggers Code Actions only when explicitly saved. This value will be deprecated in favor of "explicit".'), nls.localize('neverSaveBoolean', 'Never triggers Code Actions on save. This value will be deprecated in favor of "never".') ], <del> default: true, </del> <ins> default: 'explicit', </ins> description: description }; };

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 Version: 1.85.1 OS Version: Apple M1 Max Mac 13.6.2 Steps to Reproduce: this snippet to VSCode settings VSCode keeps changing the setting to: If I change the value back to true (a valid value), then force the settings to sync (confirming the sync happened with the new setting), then reopen VSCode again.. the value has reverted it back to "explicit" and a new sync entry (from opening VSCode) happens saying it synced that new value. If I change the value to "always" it does not change back to "explicit".
While is still allowed, I think they're trying to deprecate that and encourage usage of //. It's changing to which is equivalent to had been prior to the September 2023 release aka v1.83, see discussion in release notes and .
Probably the best fix would be actually remove true/false values as valid inputs. Keeping them as valid can/will cause confusion. While it is mentioned in those release notes, not everybody reads every release notes in detail and it still conflicts with VSCode suggesting those values as valid.
We're affected by this as well. We have committed our VS Code settings to over a dozen repositories, so any developer on v1.85 encountered this auto-migration and saw those changes in their . Fortunately, we all update our VS Code version on the same day, so the impact is reduced, but it still means there will be merge conflicts and developers will need to rebase all of their branches.

In the past, whenever a VS Code update changes a setting, the old value continues to be accepted and there's a warning message shown. This gives us ample time to migrate the settings, instead of having to drop everything and fix it like today. Going forward, please follow that old approach and do not auto-migrate the settings.
This is a breaking change, how this even got merged?
Change:
const uri = this.getUri(sessionId, chat, codeBlockIndex); const ref = this.textModelService.createModelReference(uri); this._models.set(uri, { model: ref, vulns: [] }); <ins> while (this._models.size > this.maxModelCount) { const first = Array.from(this._models.keys()).at(0); if (!first) { break; } this.delete(first); } </ins> return { model: ref.then(ref => ref.object), vulns: [] }; } <ins> private delete(codeBlockUri: URI) { const entry = this._models.get(codeBlockUri); if (!entry) { return; } entry.model.then(ref => ref.dispose()); this._models.delete(codeBlockUri); } </ins> clear(): void { this._models.forEach(async entry => (await entry.model).dispose()); this._models.clear();

Discussion:
We accumulate model references but don't really release/dispose them. Only when the chat session ends (a new model is being set)
Change:
'window.zoomLevel': { 'type': 'number', 'default': 0, <del> 'minimum': -8, 'maximum': 8, </del> <ins> 'minimum': MIN_ZOOM_LEVEL, 'maximum': MAX_ZOOM_LEVEL, </ins> 'markdownDescription': localize({ comment: ['{0} will be a setting name rendered as a link'], key: 'zoomLevel' }, "Adjust the default zoom level for all windows. Each increment above `0` (e.g. `1`) or below (e.g. `-1`) represents zooming `20%` larger or smaller. You can also enter decimals to adjust the zoom level with a finer granularity. See {0} for configuring if the 'Zoom In' and 'Zoom Out' commands apply the zoom level to all windows or only the active window.", '`#window.zoomPerWindow#`'), ignoreSync: true, tags: ['accessibility']

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 Version Version: 1.68.0 (user setup) Commit: Date: 2022-06-08T11:44:16.822Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: is not in F11 fullscreen mode. the Settings GUI, set window.zoomLevel to a negative value (e.g. -3) add an extra 0 (e.g. -30) setting is automatically applied, which leads to a state where the entire UI disappears. Clicking anywhere in the window minimizes the window. F11 fullscreen mode appears to fix this situation and the UI becomes visible again(albeit very tiny at the -30 zoom level). My initial take is this could be fixed with a sane lower bounds on window.zoomLevel. However, it appears that part of the issue is also that as window.zoomLevel becomes more negative(zooms out), the Menu Bar becomes larger. At high magnitude negative values, the Menu Bar increases in size to the point where it takes up the entire window and prevents user input. Ex.) window.zoomLevel: -20 . ! Ex.) window.zoomLevel: -30. At this level, the Menu Bar minimize "-" icon takes up the whole window.

At this level, the setting input box also de-focuses, preventing the user from pressing backspace to remove the extra 0. !
<!-- 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!
Change:
return null; } <del> const enc = guessed.encoding.toLowerCase(); // Ignore encodings that cannot guess correctly // (http://chardet.readthedocs.io/en/latest/supported-encodings.html) if (0 <= IGNORE_ENCODINGS.indexOf(enc)) { return null; } </del> return toIconvLiteEncoding(guessed.encoding); }

Discussion:
utf-8() encoding guessing is disabled by this line. But this didn't mention it. And in my test,the follow text will be guessing as utf-8 correctly(result='utf-8'). ! jschardet result: ! In the other hand,with the follow setting, it will be detect as ! !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.564 --- <!-- score: 0.49 --<!-- potentialduplicatescomment --
These issues will be solve by
In particular, will be treat as !
I like this change because it makes more deterministic by giving it full control over the detection. I still think more work is needed to increase the confidence of the detection, but that can continue in other issues.
I noticed a bad regression though that made me push to ignore the guessed encoding "ascii" for a simple reason: user opens a text file with just ascii characters we guess the encoding to be "ascii" user types special characters (like german umlaut) user saves and closes the file user reopens the file =the file is still guessed as "ascii" because it was not saved with a proper encoding
Verification: configure configure (simply to a non-UTF8 encoding) save a file with special characters contents (e.g. ) as UTF-8 close all files open it in VSCode =the encoding should be from the status bar.
Given scary issues such as I am putting UTF-16 and 32 back to the list of ignored encodings for guessing. Still, UTF-8 can be guessed.
From this issue , we really need to replace jschardet with a new library
Change:
} replaceLast(uri: URI, value: string) { <del> if (!this._history.has(uri)) { </del> <ins> const history = this._history.get(uri); if (!history) { </ins> this._history.set(uri, new HistoryNavigator2<string>([value], 50)); return; } else { <del> const history = this._history.get(uri); if (history?.current() !== value) { history?.replaceLast(value); } </del> <ins> history.replaceLast(value); history.resetCursor(); </ins> } } clearHistory(uri: URI) {

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. --four cells from the interactive window input box, e.g. , , , reexecute multiple commands from earlier in your history, e.g. and use via the up arrow executing an entry from earlier in the history e.g. , scroll position resets to the bottom of the history, and you have to start over and scroll up from the most recent command (4 -3 - 2 -1). This can be frustrating for users who are trying to reexecute multiple commands. Note also that the original interactive window used to preserve your scroll history in the interactive window so that you didn't have to scroll back up through the entire history, and users have complained about this behavior change:
The expectation is that the interactive window input behaves just like a REPL. would address this. Per discussion with we should have shared logic for handing history traversal.
Any news on that? I agree with the PR that the current behavior is quite frustrating and deserves further attention.
Yes this is one of my main frustrations with the IW still. At minimum I just want the up arrow to go to the last executed code, not have cycle through like 20 cells every time I need to re-run something. And it did used to work this way ~1.5 yrs ago.
Change:
'`${cwd}`: ' + localize("cwd", "the terminal's current working directory"), '`${cwdFolder}`: ' + localize('cwdFolder', "the terminal's current working directory, displayed for multi-root workspaces or in a single root workspace when the value differs from the initial working directory. On Windows, this will only be displayed when shell integration is enabled."), '`${workspaceFolder}`: ' + localize('workspaceFolder', "the workspace in which the terminal was launched"), <ins> '`${workspaceFolderName}`: ' + localize('workspaceFolderName', "the `name` of the workspace in which the terminal was launched"), </ins> '`${local}`: ' + localize('local', "indicates a local terminal in a remote workspace"), '`${process}`: ' + localize('process', "the name of the terminal process"), '`${separator}`: ' + localize('separator', "a conditional separator {0} that only shows when surrounded by variables with values or static text.", '(` - `)'),

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. --I usually give a meaningful name to my folders in the workspace config file, like this: It would be very useful if the integrated terminal title could show this name instead of the folder name. Currently these variables can be used in the property: ${cwd} ${cwdFolder} ${workspaceFolder} ${local} ${process} ${separator} ${sequence} ${task} The refers to the property of the folder. There could be a new variable, or something like that. Thank you in advance! Keep up the good work!
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to 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!
If this just needs to point at it should be trivial to add:
Is this still in the backlog for a future release? It would be very useful for accessibility platforms like talon voice where we rely on parsing context information out of the window title.
Change:
* viewport. */ clearBuffer(): void; <ins> /** * Clears decorations - for example, when shell integration is disabled. */ clearDecorations(): void; </ins> } export interface IRequestAddInstanceToGroupEvent {

Discussion:
Ref From
When I turn off , the padding remains. When I turn off , the decorations go away for the current terminal, even though shell integration is still on for the terminal. The padding also remains in this case. Are either of these results expected?
I don't think we're considering the setting currently, could you create a new issue on that? For were you testing for terminals that were not the left-most split? The padding should always be 20px for the left-most terminal so the character grid aligns with the first panel title. !
We are considering that: It's working for me https://user-
This is by design But shell integration should not still be on for that terminal.
I just tested it with a non-leftmost terminal now. I can confirm the padding goes away when I disable the decorations. When I re-enable them, the padding reappears, but the decorations don't seem to show up for new commands.
that one's tracked in already

Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially
Change:
} getViewScrollBottom() { <del> const topInsertToolbarHeight = this._viewContext.notebookOptions.computeTopInsertToolbarHeight(this.viewModel?.viewType); return this.getViewScrollTop() + this.view.renderHeight - topInsertToolbarHeight; </del> <ins> return this.getViewScrollTop() + this.view.renderHeight; </ins> } setCellEditorSelection(cell: ICellViewModel, range: Range) {

Discussion:
enough cells in the interactive window that it needs to scroll "interactiveWindow.alwaysScrollOnNewCell": false to the bottom of the IW and execute another cell :bug: scrollbar height changes and is at the bottom, but the new cell isn't visible
Change:
overflow: hidden; } <ins> .extension-list-item.deprecated > .details > .header-container > .header > .name { text-decoration: line-through; } </ins> .extension-list-item > .details > .header-container > .header > .activation-status, .extension-list-item > .details > .header-container > .header > .install-count, .extension-list-item > .details > .header-container > .header > .ratings {

Discussion:
Testing When I run a search for "deprecated" I see a large list of extensions that are being deprecated. I also see that each extension uses it's own ways to indicate that the extension is deprecated: prefix prefix sufix sufix Given that we control the list of deprecated extensions, and we have several established UI elements I am wondering if we could create a more unified and consistent look for all the deprecated extensions: In the extensions list, add a visual indicator in the upper left hand corner of the icon (similar to pre-release) In the extension details page, have a "deprecated" pill/badge after the name (similar to the pre-release and preview)
Another idea would be strike out the title just like we strike out in code editor.
any suggestions?
I like the strike-through on the title idea, it's simple (even though we already use the warning icon): <img width="1138" alt="CleanShot 2022-05-31 at 12 40 26 src="https://user-"
<img width="1378" alt="image" src="https://user-"
FYI
looks nice :)
Change:
precondition: null, kbOpts: { kbExpr: null, <del> primary: KeyMod.CtrlCmd | KeyCode.KEY_F, </del> <ins> primary: KeyMod.CtrlCmd | KeyCode.KEY_F } }); } public run(accessor: ServicesAccessor, editor: ICodeEditor): void { let controller = CommonFindController.get(editor); if (controller) { controller.start({ forceRevealReplace: false, seedSearchStringFromSelection: editor.getConfiguration().contribInfo.find.seedSearchStringFromSelection, shouldFocus: FindStartFocusAction.FocusFindInput, shouldAnimate: true }); } } } export class StartFindWithSelectionAction extends EditorAction { constructor() { super({ id: FIND_IDS.StartFindWithSelection, label: nls.localize('startFindAction', "Find"), alias: 'Find', precondition: null, kbOpts: { kbExpr: null, primary: null, </ins> mac: { <del> primary: KeyMod.CtrlCmd | KeyCode.KEY_F, secondary: [KeyMod.CtrlCmd | KeyCode.KEY_E] </del> <ins> primary: KeyMod.CtrlCmd | KeyCode.KEY_E, </ins> } } });

Discussion:
VSCode Version: Code 1.17.2 (, 2017-10-16T13:47:41.889Z) OS Version: Darwin x64 17.0.0 Extensions: ExtensionVersion ------ unity-tools0.1.9 unity-debug1.2.1 vscode-eslint1.3.2 python0.7.0 cpptools0.14.0 csharp1.12.1 mono-debug0.15.7 vscode-arduino0.2.9 Steps to Reproduce: the user setting "": false, text in a document command-e command-f Expected results: VS Code matches the standard Mac text find behavior, where command-e populates the search pasteboard with the current selection, but doesn't show the find panel. Pressing command-f thereafter shows the find panel, revealing what I put in there with command-e. Actual results: pressing command-e shows the find panel and doesn't populate the search pasteboard Plx to allow me to match the macOS standard behavior! Is my favest! <!-- Launch with to check. --Reproduces without extensions: Yes
Change:
return; } <del> const languageId = cell.cellKind === CellKind.Markup ? 'markdown' : (this._languageService.getLanguageIdByLanguageName(cell.language) || cell.language); const text = this._languageService.getLanguageName(languageId) || languageId; const item = <INotebookCellStatusBarItem>{ text, </del> <ins> const statusBarItems: INotebookCellStatusBarItem[] = []; let displayLanguage = cell.language; if (cell.cellKind === CellKind.Markup) { displayLanguage = 'markdown'; } else { const registeredId = this._languageService.getLanguageIdByLanguageName(cell.language); if (registeredId) { displayLanguage = this._languageService.getLanguageName(displayLanguage) ?? displayLanguage; } else { // add unregistered lanugage warning item const searchTooltip = localize('notebook.cell.status.searchLanguageExtensions', "Unknown cell language - Search for '{0}' extensions", cell.language); statusBarItems.push({ text: `$(dialog-warning)`, command: { id: 'workbench.extensions.search', arguments: [`@tag:${cell.language}`], title: 'Search Extensions' }, tooltip: searchTooltip, alignment: CellStatusbarAlignment.Right, priority: -Number.MAX_SAFE_INTEGER + 1 }); } } statusBarItems.push({ text: displayLanguage, </ins> command: CHANGE_CELL_LANGUAGE, tooltip: localize('notebook.cell.status.language', "Select Cell Language Mode"), alignment: CellStatusbarAlignment.Right, priority: -Number.MAX_SAFE_INTEGER <del> }; </del> <ins> }); </ins> return { <del> items: [item] </del> <ins> items: statusBarItems </ins> }; } }

Discussion:
Currently if we don't find language provider for cells, we would fall back to , this will make the document dirty immediately. We should actually respect the language metadata, show a warning on the cell status bar language picker and ask users to install language extensions for it.
Change:
@IWorkbenchThemeService private readonly _themeService: IWorkbenchThemeService, @IFileService private readonly _fileService: IFileService, @INotificationService private readonly _notificationService: INotificationService, <del> @ILogService private readonly _logService: ILogService </del> <ins> @ILogService private readonly _logService: ILogService, @IConfigurationService private readonly _configurationService: ConfigurationService </ins> ) { super(); this._styleElement = dom.createStyleSheet();

Discussion:
Found no duplicated for this one Currently it's hardcoded I propose a config entry for long line length If you're object, I'd like to create pull request for this feature Your thoughts?
I think this makes sense as a workspace setting that defaults to the current value. Feel free to make a PR!