jiebi/CodeConvo huggingface dataset:
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { URI } from 'vs/base/common/uri'; </ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <ins> import { matchesScheme } from 'vs/platform/opener/common/opener'; import { IProductService } from 'vs/platform/product/common/productService'; </ins> import { ITerminalSimpleLink, ITerminalLinkDetector, TerminalBuiltinLinkType } from 'vs/workbench/contrib/terminal/browser/links/links'; import { convertLinkRangeToBuffer, getXtermLineContent } from 'vs/workbench/contrib/terminal/browser/links/terminalLinkHelpers'; import { ITerminalConfiguration, TERMINAL_CONFIG_SECTION } from 'vs/workbench/contrib/terminal/common/terminal';

Discussion:
Type: <bBug</bContext I want to use vscode-URLs to directly drop into a debugging session. My script can be found at Expected behavior When cmd-clicking this link from inside VSCode, I would expect to be dropped into the debugging session <img width="1287" alt="Screenshot 2022-08-22 at 10 25 59" src="https://user-"Actual behavior Instead, the link gets opened in VS Code's search bar <img width="904" alt="Screenshot 2022-08-22 at 10 27 17" src="https://user-"Additional information I am sure the link itself is fine, because when I copy it from the console and paste it into Chrome's address bar, then VSCode opens my debugging session as expected. Also see VS Code version: Code 1.70.2 (, 2022-08-16T05:36:37.829Z) OS version: Darwin x64 21.6.0 Modes: Remote OS version: Linux x64 5.15.0-30-generic Remote OS version: Linux x64 5.15.0-30-generic <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ better-cpp-syntax1.15.19 jupyter-keymap1.0.0 remote-ssh0.84.0 remote-ssh-edit0.80.0 llvm0.1.1 vscode-clangd0.1.21 vscode-lldb1.7.4 </details<!-- generated by issue reporter --
since the url would need to open a JS/browser debug session, would the JavaScript Debugger Companion Extension be of help here?
This is debugging with lldb, so it's not in the domain of js-debug
This is a request to essentially hook up the terminal link detector to whatever handles external custom protocol links. We may be able to just add vscode:// and vscode-insiders:// to the uri detection? This may need changes in the editor's link detector
Change:
} }); }, 1000); <del> xterm.raw.onKey(e => this._onKey(e.key, e.domEvent)); </del> <ins> this._xtermOnKey = xterm.raw.onKey(e => this._onKey(e.key, e.domEvent)); </ins> xterm.raw.onSelectionChange(async () => this._onSelectionChange()); xterm.raw.buffer.onBufferChange(() => this._refreshAltBufferContextKey());

Discussion:
Testing vscode open to folder , and another folder . Have the files , , and , to folder enter in the terminal and click on it. opens in the folder. opens https://user-
Maybe I'm doing something wrong, but I can't reproduce. I have a workspace with a . It opens that before I into a new directory. I into a new directory with a and when I click on it, that one opens. !
did it look like shell integration was enabled on hover ?
Can repro, we need to also make validated local link provider aware of command detection.
this should already work as preprocessPath uses the cwd Guessing this is a windows only issue, as I'm not encountering it on mac
I think _processCwd is hooked up to the old system:
<img width="1648" alt="image" src="https://user-" is this as expected, I'm in folder and clicking on opens the quick pick other than directly opening .
if you create another terminal and hover the tab, what capabilities do you see?
hadn't enabled shell integration. he did and does see the capabilities, the run recent command works, but he said that this does not.
issue above is with word links whereas this original issue was not
Can repro, the following screenshot tries to open a link in vscode: ! !
Change:
EditorPaneDescriptor.create( GettingStartedPage, GettingStartedPage.ID, <del> localize('getStarted', "Get Started") </del> <ins> localize('welcome', "Welcome") </ins> ), [ new SyncDescriptor(GettingStartedInput) ] ); <del> const category = { value: localize('getStarted', "Get Started"), original: 'Get Started' }; </del> <ins> const category = { value: localize('welcome', "Welcome"), original: 'Welcome' }; </ins> registerAction2(class extends Action2 { constructor() {

Discussion:
Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed.

Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.
Change:
} layout(): void { <del> const dimension = getClientArea(this.window.document.body, this.container); position(this.container, 0, 0, 0, 0, 'relative'); size(this.container, dimension.width, dimension.height); </del> <ins> // Split layout up into two events so that downstream components // have a chance to participate in the beginning or end of the // layout phase. // This helps to build the auxiliary window in another component // in the `onWillLayout` phase and then let other compoments // react when the overall layout has finished in `onDidLayout`. const dimension = getClientArea(this.window.document.body, this.container); this._onWillLayout.fire(dimension); </ins> this._onDidLayout.fire(dimension); }

Discussion:
Testing a workspace a tab into a new floating window in a couple times using keyboard shortcuts the zoom status bar item to zoom out. When the zoom out happens, the status bar item will move further right, as expected because everything is getting small. However, the hover itself moved further left. I would expect it to either stay under my cursor (ideal) or move with the status bar item. !
It also moves around unexpectedly when I zoom in.
My cursor isn't showing properly in this gif, but I think you can get the idea. !
<!-- 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:
if (!this._editor || !this._editor.hasModel()) { return; } <del> const editorBox = dom.getDomNodePagePosition(this._editor.getDomNode()); const glyphMarginWidth = this._editor.getLayoutInfo().glyphMarginWidth; const leftOfContainer = this._hover.containerDomNode.offsetLeft; return editorBox.width + editorBox.left - leftOfContainer - glyphMarginWidth; </del> <ins> const bodyBoxWidth = dom.getClientArea(document.body).width; const horizontalPadding = 14; return bodyBoxWidth - horizontalPadding; </ins> } public isMouseGettingCloser(posx: number, posy: number): boolean {

Discussion:
open a file with color values (testing , ) split the editor pane, have the setting UI on the RHS resize a color picker hover :bug: it gets stuck to a wrong max width this seems not to happen having a text editor to its side
setting June for investigation
It appears the error is due to the fact that after the normal rendering, we do not fid the maximum resizable node dimensions and do not update the height or width of the widget hover if the dimensions are bigger than the resizable node max dimensions. A PR has been made here:
Change:
this.stickyEditorTabsControl = this._register(this.instantiationService.createInstance(MultiEditorTabsControl, this.parent, editorPartsView, this.groupsView, this.groupView, stickyModel)); this.unstickyEditorTabsControl = this._register(this.instantiationService.createInstance(MultiEditorTabsControl, this.parent, editorPartsView, this.groupsView, this.groupView, unstickyModel)); <del> this.handlePinnedTabsLayoutChange(); </del> <ins> this.handleTabBarsStateChange(); } private handleTabBarsStateChange(): void { this.activeControl = this.model.activeEditor ? this.getEditorTabsController(this.model.activeEditor) : undefined; this.handleTabBarsLayoutChange(); </ins> } <del> private handlePinnedTabsLayoutChange(): void { </del> <ins> private handleTabBarsLayoutChange(): void { </ins> if (this.groupView.count === 0) { // Do nothing as no tab bar is visible return;

Discussion:
Type: <bBug</bfile A from EXPLORER tab with file A file B from EXPLORER -breadcrumb shows file B path (correct) on the pinned tab with file A -breadcrumb shows file B path but should file A This is the minimal case. When I have multiple pinned tabs and open other files, the breadcrump gets more random. UPDATE: Looks like the bug only comes out if this setting is set to true: VS Code version: Code 1.92.2 (, 2024-08-14T17:29:30.058Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.153.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ macos-modern-theme2.3.19 better-cpp-syntax1.27.1 remote-containers0.380.0 remote-ssh0.113.1 remote-ssh-edit0.86.0 remote-wsl0.88.2 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.2 vscode-clangd0.1.29 regionfolder1.0.22 cmake-tools1.18.44 cpptools1.21.6 workspace-include-what-you-use0.0.3 cmake0.0.17 (4 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This doesn't reproduce for me. Please try without extensions enabled and without custom settings
I turned off extensions and custom settings. I nailed it down to this setting in It appears that the bug is reproducible only if is true.
can you help here? It seems that pinned, extra-row items don't make the call to the breadcrumbs controls, like how it is done for instance for the
Thanks for steps. could you take a look?
Thanks for reporting. When switching to the last previous active tab of the other tab bar it wasn't updating the breadcrumbs. Made a fix
<!-- 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!
Still doesn't work correctly on current insiders version. Version: 1.93.0-insider (user setup) Commit: Date: 2024-08-23T06:45:56.108Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.
Change:
import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { ILogService } from 'vs/platform/log/common/log'; <del> import { INotificationService } from 'vs/platform/notification/common/notification'; import { IStorageService, StorageScope, StorageTarget } from 'vs/platform/storage/common/storage'; </del> <ins> import { IStorageService } from 'vs/platform/storage/common/storage'; </ins> import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { badgeBackground, badgeForeground, contrastBorder, editorForeground } from 'vs/platform/theme/common/colorRegistry'; import { attachButtonStyler, attachStylerCallback } from 'vs/platform/theme/common/styler';

Discussion:
I am sure by now everyone got this: !
I used to get issues about people not sure whether settings were saved, now I don't. You should only see it once in a new user data dir. I think it's useful, I'd prefer to keep it.
I think given our latest move to reduce notifications we should revisit this. //cc
Agree. would you be open to remove this notification now? This only happens in JSON settings? This one is advanced and maybe those users do not need help?
This happens with our standard settings editor: !
Oh I misunderstood, then I would definitely remove this notification. Most UI now days do not have an Apply button and none of the notify that you do not have to click apply for the setting to be applied. did we run some user studies where participants would get confused if their settings get saved? Could we maybe remove this notification and run a short study to gather some impressions. Reopening this issue for discussion
As I remember, this came directly from user studies. But that was 3 years ago and maybe we can just assume that people are used to it now? You will also only get it once.
I don't remember the details from the user study but I think it would be fine to remove this and then also follow up with a short study.
cool. do you mind if we remove this in May debt week, so we have the whole May milestone to gather feedback and maybe do a short study?
Since I noticed this again now in endgame week with fresh installs, decided to put up a PR with the notification removed in
Awesome, thanks for doing that
verified
Change:
}; elementDispoables?: DisposableStore; } <ins> class TerminalTabsAccessibilityProvider implements IListAccessibilityProvider<ITerminalInstance> { constructor(@ITerminalService private readonly _terminalService: ITerminalService) { } getWidgetAriaLabel(): string { return localize('terminal.tabs', "Terminal tabs"); } getAriaLabel(instance: ITerminalInstance): string { let ariaLabel: string = ''; const tab = this._terminalService.getTabForInstance(instance); if (tab && tab.terminalInstances?.length > 1) { const terminalIndex = tab.terminalInstances.indexOf(instance); ariaLabel = localize({ key: 'splitTerminalAriaLabel', comment: [ `The terminal's ID`, `The terminal's title`, `The terminal's split number`, `The terminal group's total split number` ] }, "Terminal {0} {1}, split {2} of {3}", instance.instanceId, instance.title, terminalIndex + 1, tab.terminalInstances.length); } else { ariaLabel = localize({ key: 'terminalAriaLabel', comment: [ `The terminal's ID`, `The terminal's title` ] }, "Terminal {0} {1}", instance.instanceId, instance.title); } return ariaLabel; } } </ins>

Discussion:
Testing Have multiple terminal tabs open. In one tab have a couple of split terminals. Visually they look like they belong to a tree, however this information is not conveyed to the screen reader. Here are some ideas on how to improve this: Put for elements that are inside the tree. Currently all elements have an aria-level = 1. If you prefer to leave it like that then the role of the whole thing should be a and not a Modify aria label of an element in case he is part of a split
We're converting this into a list next iteration , I think we need to indicate to the screen reader that it's a split though. Not sure how the special characters are read out now.
hmm, should we be surfacing the fact that it's a split terminal to the screen reader at all? I think it's purely a UI feature so it shouldn't make a difference if you can't see the UI?
oh great that you moving to the list. You should have a correct role then. I would still convey the group number as part of the aria label, since we do the same for editors in editor groups. It is useful for users to know how things are grouped on the screen in case there are navigation actions like switch tab, or move focus inside a terminal tab. Just make sure that the group label is at the end of the list element aria label so it is easy to skip. Special character is not read out now because it is not part of the aria label.
Good point
Scoped this issue down, conversion to list will be handled in
I see the code changes which look good, however when I try this out the group is not applied to the aria label, it is the same as before. I have a ZSH, one tab with one terminal, and another tabs with two terminals. And all their labels are just
! When I inspect a split terminal tab label, it has the correct aria label.
Oh but you are setting the on the wrong HTML element You should use the so the is properly set on the element. It has to be on that element, since that element has focus and that is what the Screen Reader will read. So I think it should be fixed here
Change:
'explorer.fileNesting.patterns': { 'type': 'object', scope: ConfigurationScope.RESOURCE, <del> 'markdownDescription': nls.localize('fileNestingPatterns', "Controls nesting of files in the explorer. Each __Item__ represents a parent pattern and may contain a single `*` character that matches any string. Each __Value__ represents a comma separated list of the child patterns that should be shown nested under a given parent. Child patterns may contain several special tokens:n- `${capture}`: Matches the resolved value of the `*` from the parent patternn- `${basename}`: Matches the parent file's basename, the `file` in `file.ts`n- `${extname}`: Matches the parent file's extension, the `ts` in `file.ts`n- `${dirname}`: Matches the parent file's directory name, the `src` in `src/file.ts`n- `*`:  Matches any string, may only be used once per child pattern"), </del> <ins> 'markdownDescription': nls.localize('fileNestingPatterns', "Controls nesting of files in the explorer. {0} must be set for this to take effect. Each __Item__ represents a parent pattern and may contain a single `*` character that matches any string. Each __Value__ represents a comma separated list of the child patterns that should be shown nested under a given parent. Child patterns may contain several special tokens:n- `${capture}`: Matches the resolved value of the `*` from the parent patternn- `${basename}`: Matches the parent file's basename, the `file` in `file.ts`n- `${extname}`: Matches the parent file's extension, the `ts` in `file.ts`n- `${dirname}`: Matches the parent file's directory name, the `src` in `src/file.ts`n- `*`:  Matches any string, may only be used once per child pattern", '`#explorer.fileNesting.enabled#`'), </ins> patternProperties: { '^[^*]**?[^*]*$': { markdownDescription: nls.localize('fileNesting.description', "Each key pattern may contain a single `*` character which will match any string."),

Discussion:
and state that it only takes effect when that setting is enabled I didn't know it had to be enabled - so was confused when it didn't work
Change:
window.scroll(window.scrollX, Math.max(1, window.scrollY + scrollTo)); } <del> export function getEditorLineNumberForPageOffset(offset: number, documentVersion: number) { </del> <ins> export function getEditorLineNumberForPageOffset(offset: number, documentVersion: number): number | null { </ins> const { previous, next } = getLineElementsAtPageOffset(offset, documentVersion); if (previous) { <ins> if (previous.line < 0) { return 0; } </ins> const previousBounds = getElementBounds(previous); const offsetFromPrevious = (offset - window.scrollY - previousBounds.top); if (next) {

Discussion:
Thanks for the quick turnaround on preserving the open attribute! I'm still a little curious about the scrolling sync: I don't see anything in that looks like it would address the issue I'm seeing "scrolling past" a collapsed block where the code cursor makes the preview act as if it's much further down, seemingly by about as much as the length of the expanded . I can now leave my expanded to re-enable sync'd scrolling, but I was wondering if the intent was to not change the behavior when they're closed? Or, would it be helpful if I broke that part out into a new issue? Originally posted by in
Thanks. I've extracted this to it's own issue and will push a fix shortly
<!-- 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:
if (outputModified && !outputMetadataChangeOnly) { const originalOutputRenderListener = this.notebookEditor.onDidDynamicOutputRendered(e => { <del> if (e.cell.uri.toString() === this.cell.original.uri.toString()) { </del> <ins> if (e.cell.uri.toString() === this.cell.original.uri.toString() && this.cell.checkIfOutputsModified()) { </ins> this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Original, this.cell.original.id, ['nb-cellDeleted'], []); originalOutputRenderListener.dispose(); } }); const modifiedOutputRenderListener = this.notebookEditor.onDidDynamicOutputRendered(e => { <del> if (e.cell.uri.toString() === this.cell.modified.uri.toString()) { </del> <ins> if (e.cell.uri.toString() === this.cell.modified.uri.toString() && this.cell.checkIfOutputsModified()) { </ins> this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Modified, this.cell.modified.id, ['nb-cellAdded'], []); modifiedOutputRenderListener.dispose(); }

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.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back