jiebi/CodeConvo huggingface dataset:
Change:
'font-family': fontFamily, 'font-weight': fontWeight, 'font-size': fontSize, <ins> 'link-color': theme.getColor(textLinkForeground).toString() </ins> }; let activeTheme: ApiThemeClassName;

Discussion:
! It looks surprisingly good in this screenshot, but in reality it's way worse. Contrast ratio: background: , color:
It doesn't make much sense to me. Background color changes ... color stays the same. If background is close to blue () =links become low contrast ! If background is close to orange () =code samples become low contrast !
Change:
createCell(index: number, source: string, language: string, type: CellKind, metadata: NotebookCellMetadata | undefined, outputs: IOutputDto[], synchronous: boolean, pushUndoStop: boolean = true, previouslyPrimary: number | null = null, previouslyFocused: ICellViewModel[] = []): CellViewModel { const beforeSelections = previouslyFocused.map(e => e.handle); <ins> const endSelections: ISelectionState = { kind: SelectionStateType.Index, focus: { start: index, end: index + 1 }, selections: [{ start: index, end: index + 1 }] }; </ins> this._notebook.applyEdits([ { editType: CellEditType.Replace,

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: main branch, commit (28 march) OS Version: Linux Component: notebook When a user adds a new cell in a notebook, this created cell is automatically selected. This selection happens in the class (): However, when the user undoes and redoes this action, this new cell is not selected any more. This may be considered as an issue since undo/redo must be an identify function. I think that this issue takes sources in the method () where the current selection operation to do after the cell creation is . If I replace this arrow function by: and I removed the block of it works as expected (build, tests, integration tests OK). Steps to Reproduce: To reproduce the issue automatically, adds this test in (executed by ): I will open a PR to detail the proposal. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes (in development mode). <!-- 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. --
I created a cell, and then undo/redo a bunch on that cell and the selection isn't always the recreated cell
any chance you can do a screen recording of the reproduce?
Can't repro this anymore. Marking as verified. Don't know what happened before. Although there is some screen cheese on many undo redos it's very brief.
Change:
localize('proxySupportOverride', "Enable proxy support for extensions, override request options."), ], default: 'override', <del> description: localize('proxySupport', "Experimental setting: Use the proxy support for extensions.") </del> <ins> description: localize('proxySupport', "Use the proxy support for extensions.") </ins> } } });

Discussion:
!
<img width="552" alt="capture" src="https://user-"
Change:
} private updateDisplay() { <del> const hasChildren = this.domNode.hasChildNodes(); if (!hasChildren) { </del> <ins> const hasSticky = this.currentStickyLines.size > 0; if (!hasSticky) { </ins> this.domNode.style.display = 'none'; } else { this.domNode.style.display = 'block';

Discussion:
Tested on Windows 11. Yep, I also found it confusing as to when a sticky header would appear. Scrolling through in the testing repo, I had to scroll several times past before it would appear in the sticky scroll UI. I would have expected the header to be displayed right after it scrolled out the top of the view port. I also saw that headers higher in the hierarchy such as would disappear and reappear. Shouldn't the H2s remain as the H3s change? Originally posted by in
Somewhat related to visible range issues and multiple md cells with headers in a row.
Change:
suggestOnTriggerCharacters: true, acceptSuggestionOnEnter: true, snippetSuggestions: 'bottom', <ins> emptySelectionClipboard: true, </ins> tabCompletion: false, wordBasedSuggestions: true, suggestFontSize: 0,

Discussion:
Like the title says, when nothing is selected, copying shouldn't copy a blank character.
As of now, cmd+c without any selection, copies the entire line. Sublime also does the same. Are we suggesting to change this behavior as part of this issue? I really like the current functionality. Or are we suggesting one more option/flag which user can enable to have the new functionality?
Yes, it would be behind an option
Can we have the option for this behavior or disable it? I don't like the auto copy of a blank line and would like to disable that feature. I agree it can be annoying especially in the type of coding I do (debugging).
Was a setting for this?
it is
disables the line copying entirely. Is there a way to have line copying enabled, while simultaneously ignoring the empty lines?
This doesn't disable the copying within my VS Code at all and I can still copy whitespace - anyone else had any luck? fingers crossed
Change:
renderCompressedElements(node: ITreeNode<ICompressedTreeNode<FolderMatch>, any>, index: number, templateData: IFolderMatchTemplate, height: number | undefined): void { const compressed = node.element; const folder = compressed.elements[compressed.elements.length - 1]; <del> folder.compressionStartParent = compressed.elements[0]; </del> const label = compressed.elements.map(e => e.name()); if (folder.resource) {

Discussion:
! repro steps a search that has a compressed node outside of the viewport to keep collapsing gets stuck when trying to collapse all.
repro: the repo folder into a multi-root workspace (where another workspace also has the word "debug" somewhere in it). for the string "debug" clicking the Collapse All button a bunch of times gets stuck after a few times :bug: This is because the tree needs info from the function, which hasn't been run yet since the "compressed" element is off of the view. Therefore, when I'm calling , I eventually get to the "compressed" element that doesn't have the info that I need.
What is the best way to collapse all nodes of a tree at a certain level? My current (buggy) strategy involves iterating through the nodes via and collapsing them based on element types, but that depends on knowing the parent-most node in a compression (which I store when I use ).
This is strange. Despite the elements never being rendered, the tree should know exactly which elements have been compressed. The function should never create any state that other code depends on... it's purely a rendering function. At a glance the problem seems to be that you're modifying the tree (collapsing element) as you iterate it (using navigator). Can you refactor that action such that it first collects all elements which should be collapsed and, once all are collected, calls on each?
oops, figured it out! Follow-up question: how do I collapse part of a compressed node? (ie: collapsing so that only the parent is visible?) I tried calling on the parent element and it seems to assume that I just want the existing compressed node collapsed.
Unsure what you mean. Take this example: ! In this scenario, , and are just one node, for all purposes. Do you mean you want to collapse , for example? What should be the visual outcome of that?
Yes, I'd be talking about collapsing or . Now that you mention it, it would be confusing to collapse partway like that. The reason I bring this up is because the "collapse/expand` button in search is multi-step in multi-root and tree modes. Ie: in multi-root, the collapse/expand would go: collapse button once: collapses all nodes one level below root collapse again: collapses all root nodes. everything.

and repeat How would you imagine that it should handle the first collapse if it's a compressed series of folders (ie: )? I was originally thinking that it would just compress , but that would have a weird visual outcome. Do you know anywhere else where we do something like this?
I would expect the node would be collapsed in that case. The key here is nodes, not folders. The node represents three folders.
Change:
// foo:339 // foo:339:12 // foo 339 <del> // foo 339:12                    [#140780] </del> <ins> // foo 339:12                        [#140780] </ins> // "foo",339 // "foo",339:12 <del> `(?::| |['"],)${l()}(:${c()})?$`, // The quotes below are optional [#171652] // "foo", line 339                [#40468] </del> <ins> `(?::| |['"],)${l()}(:${c()})?` + eolSuffix, // The quotes below are optional     [#171652] // "foo", line 339                   [#40468] </ins> // "foo", line 339, col 12 // "foo", line 339, column 12 // "foo":line 339

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. --originally posted here: when using the OCaml ecosystem (in my example ) the errors can't be clicked on in the terminal: <img width="736" alt="Screenshot 2023-01-19 at 10 06 47 PM" src="https://user-"I often can't click on the file because it isn't relative to where I am, and when I can click it doesn't get me to the line number. I'm not sure how other languages do it but I don't remember having that problem in other ecosystems. I'm also not sure how to fix it. I believe the terminal / vscode will detect filename:linenumber all the time, but the "File "", line 588, characters 50-75" is not recognized.
yeah looks like we don't support that case atm, though this one comes close
<!-- -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!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
The situation is pretty good on Insiders after the many link changes that have gone in since December: ! Keeping this open to also match the part and ideally select the actual range in this case.
what's Insiders? EDIT: the beta,
I'm enjoying the improvement, but the pattern still doesn't work, e.g.: Thanks!
is that a real example or did you make up the characters part? I'm not sure what multi-line and multi-character means exactly
Forking proper multi-line support to , we should be able to support the simple case of just going to the first line easily in the one.
Thank you for your work!

It's a real example, just going to the first line is good enough for me! The meaning of is "in the selection within file F, spanning from line N1, character/column C1 to line N2, character/column C2" (subject to off-by-one errors, I don't remember how the characters are counted).
Oh ok, that makes sense
FYI the row/col end part of the link should work when is merged
Change:
} await doc.save(); <del> await repository.add([uri]); </del> // TODO@jrieken there isn't a `TabInputTextMerge` instance yet, till now the merge editor // uses the `TabInputText` for the out-resource and we use that to identify and CLOSE the tab const { activeTab } = window.tabGroups.activeTabGroup; <ins> let didCloseTab = false; </ins> if (activeTab && activeTab?.input instanceof TabInputText && activeTab.input.uri.toString() === uri.toString()) { <del> await window.tabGroups.close(activeTab, true); </del> <ins> didCloseTab = await window.tabGroups.close(activeTab, true); } // Only stage if the merge editor has been successfully closed. That means all conflicts have been // handled or unhandled conflicts are OK by the user. if (didCloseTab) { await repository.add([uri]); </ins> } }

Discussion:
a merge conflict. Open merge editor not react on any conficts. Click on Accept Merge shows up. The Yours / Theirs editors get empty in the background before I have reacted in the dialog If I click cancel now I am in a broken state. I can repro 100%. ! fyi
The accept command triggers a close of the merge editor and while that happens the confirm logic kicks in...
Problem is that the accept-command ignores that the editor didn't actually close and proceeded with staging the file. That triggers file events which empty input1/2
Looks good now -verified
Change:
y18n "^5.0.5" yargs-parser "^21.0.0" <del> yargs@^17.7.2: </del> <ins> yargs@^17.7.1, yargs@^17.7.2: </ins> version "17.7.2" resolved "https://registry.yarnpkg.com/yargs/-/yargs-17.7.2.tgz#991df39aca675a192b816e1e0363f9d75d2aa269" integrity sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w==

Discussion:
<img width="415" alt="image" src=""Looks localized here though, and hasn't changed in 13 months
language pack looks ok too... Looking into this some more... it seems that the new lines aren't being handled properly.
This still repros :/ is the loc pipeline maybe not running?
it is the newlines... which I thought I fixed... sigh... They are being escaped in the language pack: if I manually delete these extra slashes locally, the problem goes away.
Update... the text has change: Now it's using when it should use and I think I know why. So exporting looks find: is turned in to (we do this manually and it's the XML way to say ) but what we get from the translators... they replace with actual new lines That's not what I was expecting. I would expect them to use the encoded characters but they're not. hacky quick fix that fixes likely most of the scenarios: more accurate longer fix: now that I think about it, this is probably the correct workaround for extensions as well
<img alt="image" src=""Looks like it works now
Change:
return [...this._repositories.values()]; } <del> constructor(private readonly globalState: Memento) { } </del> <ins> constructor(private readonly globalState: Memento) { this.onDidChangeRepositories(); } </ins> addRepository(repository: string): void { this._repositories.add(repository);

Discussion:
Open a folder with no git repo <img width="363" alt="image" src=""in an older version of vscode I see this <img width="414" alt="image" src=""
Change:
await this.code.dispatchKeybinding('enter'); await this.quickinput.waitForQuickInputClosed(); } <del> if (commandId === TerminalCommandId.Show || commandId === TerminalCommandId.CreateNewEditor || commandId === TerminalCommandId.CreateNew || commandId === TerminalCommandId.NewWithProfile) { return await this._waitForTerminal(expectedLocation === 'editor' || commandId === TerminalCommandId.CreateNewEditor ? 'editor' : 'panel'); </del> <ins> switch (commandId) { case TerminalCommandId.Show: case TerminalCommandId.CreateNewEditor: case TerminalCommandId.CreateNew: case TerminalCommandId.NewWithProfile: await this._waitForTerminal(expectedLocation === 'editor' || commandId === TerminalCommandId.CreateNewEditor ? 'editor' : 'panel'); break; case TerminalCommandId.KillAll: await this.code.waitForElements(Selector.Xterm, true, e => e.length === 0); break; </ins> } }

Discussion:
With support for for Electron tests, we should enable terminal tests: I eagerly had enabled them but since we don't know whether Electron smoke tests with are stable, I moved back to only running them in web. We should not enable these tests until we are sure, smoke tests are stable, so maybe this should only happen in May.
Failing macOS run for reference: !
Still not passing, deferring to a debt week
Change:
export async function readFromStdin(targetPath: string, verbose: boolean, onEnd?: Function): Promise<void> { let [encoding, iconv] = await Promise.all([ <del> resolveTerminalEncoding(verbose),	// respect terminal encoding when piping into file import('@vscode/iconv-lite-umd'),	// lazy load encoding module for usage fs.promises.appendFile(targetPath, '') // make sure file exists right away (https://github.com/microsoft/vscode/issues/155341) </del> <ins> resolveTerminalEncoding(verbose),		// respect terminal encoding when piping into file import('@vscode/iconv-lite-umd'),		// lazy load encoding module for usage fs.promises.appendFile(targetPath, '') 	// make sure file exists right away (https://github.com/microsoft/vscode/issues/155341) </ins> ]); <del> if (!iconv.encodingExists(encoding)) { </del> <ins> if (!iconv.default.encodingExists(encoding)) { </ins> console.log(`Unsupported terminal encoding: ${encoding}, falling back to UTF-8.`); encoding = 'utf8'; }

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: OS Version: and Steps to Reproduce: reports the following error and fails to read from stdin. I have located the root cause:
Great catch!
The fix should be in, could you verify after having pulled in the latest insiders update?
Yes, it works on the latest insiders with commit . Thank you :heart:.
Change:
super('update.openLatestReleaseNotes', nls.localize('releaseNotes', "Release Notes"), undefined, true); } <del> run(): Promise<any> { </del> <ins> async run(): Promise<void> { </ins> if (this.productService.releaseNotesUrl) { const uri = URI.parse(this.productService.releaseNotesUrl); <del> return this.openerService.open(uri); </del> <ins> await this.openerService.open(uri); </ins> } <del> return Promise.resolve(false); </del> <ins> throw new Error('This version of Visual Studio Code does not have release notes online'); </ins> } }

Discussion:
Issue Type: <bBug</bIf you try to open the release notes while offline, then if a release notes url is configured then vscode will open it in a browser, otherwise it will do nothing, not even show an error. Later, if you go online and try opening the release notes again, the same will happen - vscode will never attempt to open the release notes webview again. This state is preserved until you reload the window. Steps to Reproduce: offline (you can also open devtools in vscode and go to the network tab and change the "online" at the top to "offline") to open the release notes using from the command palette. on whether you are on an official vscode build or a local build, the release notes page will be opened in your default browser. On a local build nothing happens. back online to open the release notes again same thing will happen the window using from the command palette to open the release notes again release notes open in a webview inside vscode VS Code version: Code - Insiders 1.47.0-insider (, 2020-06-26T06:20:06.931Z) OS version: Windows_NT x64 10.0. Does this issue occur when all extensions are disabled?: Yes
Change:
event.immediate = true; this.searchBox.setValue(value); <ins> this.searchBox.setPosition(new Position(1, value.length + 1)); </ins> } private triggerSearch(immediate = false): void {

Discussion:
Steps to Reproduce: the extensions view, use the menu to use any of the pre-cooked filters (Show Enabled/Disabled/Installed/Recommended extensions) cursor should be at the end of the search text but instead its in the start of the search text This is a regression. In 1.25.1 the cursor does show up at the end of the text
Change:
assertRangeEqual(link4.range, new vscode.Range(0, 50, 0, 59)); } }); <ins> // #107471 test('Should not consider link references starting with ^ character valid', () => { const links = getLinksForFile('[^reference]: https://example.com'); assert.strictEqual(links.length, 0); }); </ins> });

Discussion:
(Apologize in advance if this is the wrong place to file this, I'm having trouble tracking down the right place.) When I make a Markdown footnote, like the first word or letter is underlined and when I right-click it it offers to . <img width="473" alt="image" src="https://user-"
VS Code's built-in markdown extension targets standard markdown, which doesn't include footnote support. As a compromise, we could update the regular expression the built-in markdown extension uses to find clickable links to exclude links starting with Starting point in code:
Yeah, thanks. That's an understandable perspective. I might do a PR for this myself. One question that still confuses me though, why does it say "Execute command" (and not "Follow link" like other links show)? <img width="597" alt="Follow Link" src="https://user-"
First day looking at the code base, so I could be off on this, but looks like the logic for when "Execute Command" is displayed is in this function: Also, are you planning on doing a PR for this still? If not I can do it.
Thanks for the additional info! Please go ahead if you're ready to work on a PR now.
I may be wrong about this, however it seems to me the problem is with how validates a definition link. In the image below notice how the last line is considered valid, and would have a tooltip and underline in the editor. ! The regex produces a valid match since the last capture group ignores everything past the first space after the link. What if we modified the expression to something like this? (tests pass) !
Yes looks like the regular expression may just need to be updated, either to check that there are not multiple words after the references or to check that the definition does not start with