jiebi/CodeConvo huggingface dataset:
Change:
import { tail } from 'vs/base/common/arrays'; import { timeout } from 'vs/base/common/async'; import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; <del> import { combinedDisposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { combinedDisposable, DisposableStore, MutableDisposable, toDisposable } from 'vs/base/common/lifecycle'; </ins> import { extUri } from 'vs/base/common/resources'; import { URI } from 'vs/base/common/uri'; import 'vs/css!./media/breadcrumbscontrol';

Discussion:
profile on startup and have a css file opened the registers a fs provider for this somehow ends up causing a dom layout via the breadcrumbs <img width="606" alt="image" src="https://user-"
The trigger is that registering a file system causes a label service change event which causes breadcrumbs to re-render. Tho, we can likely optimise this
Change:
readonly pending: boolean; /** Marks that a session did trigger the breakpoint. */ <del> setSessionDidTrigger(sessionId: string): void; </del> <ins> setSessionDidTrigger(sessionId: string, didTrigger?: boolean): void; </ins> /** Gets whether the `triggeredBy` condition has been met in the given sesison ID. */ getSessionDidTrigger(sessionId: string): boolean;

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.93.1 OS Version: Windows 11 Pro Originally from To Reproduce Steps to reproduce the behavior: an empty dart project (can be any language, this is just the one I use of course) the code below breakpoints on both and print calls the breakpoint on the trigger only after the one at (screenshot) the code and make sure the breakpoint stops the program that triggers before Expected behavior For the triggered breakpoint to wait again on restart. Also note that there are two ways to restart a debug session too - a full restart handled by VS Code (which is what happens for Dart above), and a restart that is delegated to the debug adapter (which we use for Flutter to do Hot Restart, so it's faster than a cold restart by VS Code). In both cases, this state should be reset. Screenshots ! <details<summaryRelevant debugging log part </summary</details// CC:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.93.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Interestingly, I cannot reproduce this with JavaScript using an equivalent file: Unfortunately I don't think it uses DAP and I don't know if there's a way to get a log of what's happening there. It's not clear to me how it could be working there given the DAP traffic captured for Dart. Someone familiar with the implementation of Triggered Breakpoints or the JS debugger might be able to explain what's going on.

I can on python:
I am also running into this issue
This is probably because the JS debugger has each debugee as its own, child session, and when restarting JS you will retain the parent session (handled by the DA) but get a new child session that doesn't have the data set.
I am debugging Go. I don't remember seeing it with other languages but I also only rarely run anything other than Go.
yea, it's reproducable with Python too. Fixed in Monday's Insiders.
Change:
if (body) { for (let i = 0; i < body.length; i++) { let element = body[i]; <del> let item = new MyCompletionItem(element); item.document = document; item.position = position; </del> <ins> let item = new MyCompletionItem(position, document, element); </ins> completionItems.push(item); } }

Discussion:
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-07T07:05:09.124Z) OS Version: Darwin x64 16.1.0 Steps to Reproduce: ! Enter !
That's a really annoying bug! Not just in .
The TypeScript extension tells the editor to only delete the 2 preceding characters, not the entire word. That might be a problem with the work definition you are using. !
I have extrapolated about snippets to the following piece of code
I think that Typescript needs to be explicit in this case, and provide a range for the completion items. We currently automatically pick up the range from
do you know if this is tracked on TS's side? I want to make sure I have it tracked in the OneNote table appropriately.
I don't think this is an issue on the TypeScript side. The bug was that we were relying on the default VSCode logic for determining what word to replace, and it breaks words that contain or any other non letter or digit characters. The result TypeScript provides to us is correct as far as I know
Change:
renderOptions: { after: { contentText, <del> backgroundColor: 'rgba(255, 200, 0, 0.2)', margin: '10px' }, dark: { after: { color: 'rgba(255, 255, 255, 0.5)', } }, light: { after: { color: 'rgba(0, 0, 0, 0.5)', } </del> <ins> backgroundColor: themeColorFromId(debugInlineBackground), margin: '10px', color: themeColorFromId(debugInlineForeground) </ins> } } };

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. --The inlines values colors are currently hardcoded: These should be abstracted to a themable color, either its own dedicated color or one of the , I would recommend hint or info.
I agree with this. Let's put a help wanted, sounds like a good thing to be tackled by the community. If nobody is interested I can also look into this in the future
Thanks to this is now fixed can you maybe try this out with VS Code insiders from tomorrow and let us know how it works for you. The new color names are:
Thank you, will test. Cc EDIT: Doesn't appear to have landed in yesterdays insiders, will check tomorrow.
Change:
// Button(s) if (item.refRemote) { const matchingRemote = this.repository.remotes.find((remote) => remote.name === item.refRemote); <del> const remoteUrl = matchingRemote?.pushUrl ?? matchingRemote?.fetchUrl; if (remoteUrl) { item.buttons = this.buttons.get(item.refRemote); </del> <ins> const buttons = []; if (matchingRemote?.pushUrl) { buttons.push(...this.buttons.get(matchingRemote.pushUrl) ?? []); } if (matchingRemote?.fetchUrl && matchingRemote.fetchUrl !== matchingRemote.pushUrl) { buttons.push(...this.buttons.get(matchingRemote.fetchUrl) ?? []); } if (buttons.length) { item.buttons = buttons; </ins> } } else { item.buttons = this.defaultButtons;

Discussion:
Type: <bBug</bSteps to reproduce: need a git repo with origin (your fork) and upstream (the project you forked). now you have: origin/main and upstream/main the VSCode statusbar click "Select Branch/Tag...", so that the menu with "Select branch or tag for checkout..." opens menu contains additional links for "origin/main" and "upstream/main" entries: the first icon is Github - "Open on Github" the second icon is World - "Checkout on " Issue: When you click the "Open on Github" icon for the repo it will open the repository website for = URL . This is also true for all other branches. In other words: all links point to the webpage of the parent repo . You can not open webpages for branches like . This results in 404, because it tries to open the webpage for branch on , which exists only on the child repo. Output of : Expected: When clicking "Open on Github" for the webpage for the origin repo should open. When clicking "Open on Github" for the webpage for the upstream repo should open. ! VS Code version: Code 1.82.2 (, 2023-09-14T05:55:25.390Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
I see the opposite behaviour. I forked and cloned my fork locally, then opened the folder in VS Code. In the branch quickpick I typed and was offered , and . The GH buttons on the latter two both take me to my fork in a browser (i.e. origin/main). Here's my info:
I am able to reproduce the issue using a fork of , could you please take a look? Thanks!
Change:
"input.border": "#0000001a", "input.foreground": "#000000e4", "input.placeholderForeground": "#00000079", <ins> "inputOption.activeBackground": "#005fb841", "inputOption.activeBorder": "#005FB8", "inputOption.activeForeground": "#000000", </ins> "keybindingLabel.foreground": "#000000e4", "list.activeSelectionBackground": "#e8e8e8", "list.activeSelectionForeground": "#000000",

Discussion:
Notice how the is supposed to draw a border over an active checked toggle, for example find widget. The default colors all use a opacity of it seems from the change in I do not understand the intent, but with that opacity I see the color not being applied at all. Here is how the color compares today vs. how it was intended to be when I remove the trailing : <img width="541" alt="image" src="https://user-"<img width="527" alt="image" src="https://user-"
Actually found this from the feedback widget where the selected sentiment does not indicate anymore: <img width="328" alt="image" src="https://user-"vs <img width="347" alt="image" src="https://user-"
Change:
import { ChildProcess, spawn, SpawnOptions } from 'child_process'; import { chmodSync, existsSync, readFileSync, statSync, truncateSync, unlinkSync } from 'fs'; <del> import { homedir, tmpdir } from 'os'; </del> <ins> import { homedir, release, tmpdir } from 'os'; </ins> import type { ProfilingSession, Target } from 'v8-inspect-profiler'; import { Event } from 'vs/base/common/event'; import { isAbsolute, join, resolve } from 'vs/base/common/path';

Discussion:
Testing macOS Mojave 10.14.6 Version: 1.61.0-insider (Universal) Commit: Date: 2021-09-28T05:14:06.244Z Electron: 13.4.0 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 18.7.0 open terminal run
Same with
Nice catch! Two things to be done: 1) Rewire the cli to use old code path for macOS <= 10.15 for the endgame 2) Write wrapper around to be used instead of as follow-up.
Can someone explain what is different in Big Sur compared to older versions?
from the error above the following 3 std pipe arguments are not available on older distros. tool is not public, so I couldn't find the exact release notes where this behavior was changed. For now, the safer change is to not use the path pre Big Sur while we explore alternatives using for these versions in upcoming milestone.
Ok thanks, do we have an issue for that?
Tracked in
Change:
get disableWorkspaceTrust(): boolean { return !!this.args['disable-workspace-trust']; } @memoize <ins> get disableKeytar(): boolean { return !!this.args['disable-keytar']; } @memoize </ins> get policyFile(): URI | undefined { if (this.args['__enable-file-policy']) { const vscodePortable = env['VSCODE_PORTABLE'];

Discussion:
Tracking issue to ensure that we can run a build with all tests passing, mainly smoke tests. Previously tracked as
Change:
import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { XtermLinkMatcherHandler } from 'vs/workbench/contrib/terminal/browser/links/terminalLinkManager'; import { TerminalBaseLinkProvider } from 'vs/workbench/contrib/terminal/browser/links/terminalBaseLinkProvider'; <ins> import { normalize } from 'vs/base/common/path'; </ins> export class TerminalWordLinkProvider extends TerminalBaseLinkProvider { private readonly _fileQueryBuilder = this._instantiationService.createInstance(QueryBuilder);

Discussion:
You could resolve these so it would search for the right file. Or do you not want to make assumptions about the format of the thing? ! !
Started a discussion in , if that's no good I can just normalize the path which isn't super smart but it will find results.
Open to PRs, more detailed repro in
I would like to work on this issue. We only want to normalize the path in the filter string, right? So: - a/../b/./c -b/c
yes, but just for the
I have raised a PR for this issue. Please review it.
Change:
}, [TerminalSettingId.ShellArgsWindows]: { restricted: true, <del> markdownDescription: localize('terminal.integrated.shellArgs.windows', "The command line arguments to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_configuration)."), </del> <ins> markdownDescription: localize('terminal.integrated.shellArgs.windows', "The command line arguments to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles)."), </ins> 'anyOf': [ { type: 'array', items: { type: 'string', <del> markdownDescription: localize('terminal.integrated.shellArgs.windows', "The command line arguments to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_configuration).") </del> <ins> markdownDescription: localize('terminal.integrated.shellArgs.windows', "The command line arguments to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles).") </ins> }, }, { type: 'string', <del> markdownDescription: localize('terminal.integrated.shellArgs.windows.string', "The command line arguments in [command-line format](https://msdn.microsoft.com/en-au/08dfcab2-eb6e-49a4-80eb-87d4076c98c6) to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_configuration).") </del> <ins> markdownDescription: localize('terminal.integrated.shellArgs.windows.string', "The command line arguments in [command-line format](https://msdn.microsoft.com/en-au/08dfcab2-eb6e-49a4-80eb-87d4076c98c6) to use when on the Windows terminal. [Read more about configuring the shell](https://code.visualstudio.com/docs/editor/integrated-terminal#_terminal-profiles).") </ins> } ], default: [],

Discussion:
The settings point at Should be
can i work in this issue
sure
Thanks, I started looking at the vs code a few days ago. can you help me a little bit? how to open vscode user guide link from settings. Like I opened the settings from the file-preferences-settings-terminal but I didn't find any way to open that link in vs code.
These settings are a little special as they're deprecated so they won't show up in the UI. If you switch to the JSON file you can add the setting manually like this and then hover it: ! !
The link is pointing to terminal-profiles instead of configuring-profiles but I think that is fine, considering the configuring-profiles section is right underneath, and that pointing to terminal-profiles allows users to learn more about profiles.
Change:
| IShowMarkdownMessage | IHideMarkdownMessage | IUnhideMarkdownMessage <ins> | IUpdateMarkdownPreviewSelectionState </ins> | IInitializeMarkdownMessage | IViewScrollMarkdownRequestMessage;

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. --- VS Code Version: 1.54-Insiders OS Version: macOS open a GitHub issue notebook cmd+shift+o navigate down only code cells are highlighted https://user- <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --

Verifying in the vscode repo across some of the markdown headers ! If I put them into edit mode, then I see the background change on multiselect
I guess you don't see this issue when commenting out from the workspace setting?
Yeah, that's correct! I see everything get highlighted as expected when that setting is off
The root cause is that the for webview backed markdown cells has a height of zero. This element gets the correct background color during selection, but is not visible due to the height. We have zero height so that you can click through to the webview instead of to the cell I will prototype telling the cell in the webview if it is selected or not. Then we can add styling inside the webview to show selection state
Change:
*/ static loadAddon(addon: string): void; } <del> export = Terminal; </del> }  No newline at end of file

Discussion:
Upstream issue: Please verify this on Linux by opening tmux in mouse mode and ensuring regular mouse selection triggers "tmux selection" and shift+mouse selection triggers the regular terminal selection.
I thought I verified this last month?
this was Mac only last month, needs verification on Linux.

Scrolling within the integrated terminal doesn't scroll curses interfaces such as , , , etc. <!-- Use Help Report Issues to prefill these. --- VSCode Version: Version 1.15.0 OS Version: Arch Linux Shell: ZSH (oh-my-zsh) the integrated terminal ( ``) a curses style pager interface (e.g. , , , ) the mouse scrollwheel to try and scroll the pager happens, using keyboard commands to scroll works fine (, , , , arrow keys, etc) a seperate terminal (e.g. or ) step 2 & 3 above as expected; pager scrolls <!-- Launch with to check. --Reproduces without extensions: Yes
This should be fixed in the next version. Note that this only applies to applications that launch the alt buffer however, so it does not apply to . Upstream issue:
Sounds like the upstream issue might be a different one to this. It appears to be about the alternative buffer being rendered twice after a scroll. This is about passing scroll events to pager style programs, such as less and git log.
The reason scroll isn't making it to the terminal app is because the scrollbar is grabbing the event and not passing it to the terminal. When there is no scrollback it gets sent to the terminal correctly.
It works in tmux fine now but not vim yet.
This has been working for a few versions now
Change:
import * as assert from 'assert'; import { IFullSemanticTokensDto, IDeltaSemanticTokensDto, encodeSemanticTokensDto, ISemanticTokensDto, decodeSemanticTokensDto } from 'vs/workbench/api/common/shared/semanticTokensDto'; <ins> import { VSBuffer } from 'vs/base/common/buffer'; </ins> suite('SemanticTokensDto', () => {

Discussion:
This was spotted by when working. There are no steps to reproduce because this has to do with how a specific part of an extension host message (the semantic tokens dto) aligns on bytes in the underlying nodejs stream. I can reproduce through unit testing. This can lead to semantic tokens becoming stale and not updating.
The fix is now in and also in
There is a unit test for this case and there are no steps to verify =giving label.
Change:
appendLinesToResult(baseLines, LineRange.fromLineNumbers(baseStartLineNumber, baseLines.length + 1)); <del> return resultLines.join('n'); </del> <ins> return resultLines.join(this.resultTextModel.getEOL()); </ins> } public hasBaseRange(baseRange: ModifiedBaseRange): boolean {

Discussion:
Type: <bBug</bWhen rebasing a big change on the TypeScript codebase today, I ended up with a diff that didn't make sense; I traced it down to having committed the wrong newlines. I am in WSL2, so the line ending VS Code uses is LF. However, the TS repo's files are CRLF, and are checked out as CRLF even on Linux. (Normally, VS Code saves LF, then I convert it to CRLF after a lint rule complains; in the future I'll probably just use the line ending setting and hope it works.) When I was rebasing, I hit a merge conflict; I opened the conflicted file in the source control view, and did my merge. But, when I committed the file, it appears as though the file was saved as LF and I committed it like that. I ended up having to rebase my whole stack again and run unix2dos on each until I restored the line endings. I recall something in the update blog post mentioning that the merge editor was implemented by reconstructing a new document from the two input files; perhaps this isn't taking into account the line endings of the original files? I don't recall this happening in previous versions. VS Code version: Code 1.72.0 (, 2022-10-04T23:20:39.912Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.15.57.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ remote-wsl0.72.0 atom-keybindings3.0.9 material-theme3.15.5 gitlens12.2.2 todo-tree0.0.215 vscode-duplicate1.2.1 js-debug-nightly2022.10.617 vscode-typescript-next4.9. </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I cannot reproduce (on windows, with CRLF as VS Code default and LF files). Can you reproduce? (ideally with steps on a fresh repository) It should use the line-endings style from the result file.

This just occurred to me again just the following day; I can reproduce this with a cherry pick, so that is probably going to be easier for me to make an examples with. I'll try and make one.
Also, you are using the new 3 way merge editor, right (explicitly clicking the blue button in the bottom "Open/Resolve in Merge Editor")?
Yes, that's correct, not the inline one where it's just sugar on top of a file with the lines.
I've made an example repo here: It reproduces reliably for me. Here's a screencast. !
Thank you, I can reproduce it now! Unfortunately it always resets the EOL to LF (in my test, I checked if LF files stay LF files after merging, as CRLF is the default on my system). I (implicitly) assumed would normalize the EOL style the same way does, which is apparently not the case.
Many thanks!
Verification steps: Have a conflict in a repo where all files are CLRF Solve the conflicts in the new merge editor and complete the merge Ensure the staged file also has CRLF line endings Do the same with LF files.
Change:
"@emmetio/html-matcher": "^0.3.3", "@emmetio/math-expression": "^0.1.1", "image-size": "^0.5.2", <del> "vscode-emmet-helper": "^1.2.15" </del> <ins> "vscode-emmet-helper": "^1.2.15", "vscode-html-languageservice": "^3.0.3" </ins> } }

Discussion:
Issue Type: <bFeature Request</bI'm not talking about the editor's horizontal scroll is a very thin scroll bar between the tabs and editor,that's what i'm talking about. When you open too many tabs,some tabs are invisible so you need scrolling horizontally. There's a scrollbar to scroll the tabs,but it's too thin. Of course,this wasn't a big bug or what,and I can use "Ctrl+Tab" to switch tabs. maybe this bar should be bigger or even disappear considering it's not helpful. VS Code version: Code 1.32.3 (, 2019-03-14T23:43:35.476Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.49 --<!-- potentialduplicatescomment --
Duplicate of
Oops, tagged wrong issue.