jiebi/CodeConvo huggingface dataset:
Change:
return this._ptyService.getWslPath(original); } <del> private _setTerminalLayoutInfo(args: ISetTerminalLayoutInfoArgs): void { this._ptyService.setTerminalLayoutInfo(args); } private async _getTerminalLayoutInfo(args: IGetTerminalLayoutInfoArgs): Promise<ITerminalsLayoutInfo | undefined> { return this._ptyService.getTerminalLayoutInfo(args); } </del> private _reduceConnectionGraceTime(): Promise<void> { return this._ptyService.reduceConnectionGraceTime();

Discussion:
Also repro's in stable
unsure when this started happening. I don't see any open issues about it, which makes me think this is expected in WSL?
was last working in stable 1.59
and because it was broken in stable 1.60, we can narrow it down - the breaking change happened in August
looks like perhaps a race condition - get layout info is called w the correct workpsaceId, but then set layout info is called so might be wiping out the stored info before the reconnect can occur.
I open a terminal in a Remote-SSH window, reload the window, it is not reconnected
still doesn't work for WSL. based on my investigation, the pty service gets re-created when the window is reloaded, thus losing the and maps
when connected to localhost via ssh, reloading does persist the terminals but I thought this would still be using the ... !
Yep !
Also working for me in codespaces https://user-
It does work in WSL. interestingly, other state isn't persisted that should be though (see the layout change) !
this works on all remote platforms based on my testing. i saw a few times reloading WSL didn't work, but now cannot reproduce
Oh cool, I thought the situation was much worse. I'll reopen to verify on my side since we definitely want to make sure this is working everywhere
All seems to work
verified
Change:
export const inputBackground = registerColor('input.background', { dark: '#3C3C3C', light: Color.white, hcDark: Color.black, hcLight: Color.white }, nls.localize('inputBoxBackground', "Input box background.")); export const inputForeground = registerColor('input.foreground', { dark: foreground, light: foreground, hcDark: foreground, hcLight: foreground }, nls.localize('inputBoxForeground', "Input box foreground.")); export const inputBorder = registerColor('input.border', { dark: null, light: null, hcDark: contrastBorder, hcLight: contrastBorder }, nls.localize('inputBoxBorder', "Input box border.")); <del> export const inputActiveOptionBorder = registerColor('inputOption.activeBorder', { dark: '#007ACC00', light: '#007ACC00', hcDark: contrastBorder, hcLight: contrastBorder }, nls.localize('inputBoxActiveOptionBorder', "Border color of activated options in input fields.")); </del> <ins> export const inputActiveOptionBorder = registerColor('inputOption.activeBorder', { dark: '#007ACC', light: '#007ACC', hcDark: contrastBorder, hcLight: contrastBorder }, nls.localize('inputBoxActiveOptionBorder', "Border color of activated options in input fields.")); </ins> export const inputActiveOptionHoverBackground = registerColor('inputOption.hoverBackground', { dark: '#5a5d5e80', light: '#b8b8b850', hcDark: null, hcLight: null }, nls.localize('inputOption.hoverBackground', "Background color of activated options in input fields.")); export const inputActiveOptionBackground = registerColor('inputOption.activeBackground', { dark: transparent(focusBorder, 0.4), light: transparent(focusBorder, 0.2), hcDark: Color.transparent, hcLight: Color.transparent }, nls.localize('inputOption.activeBackground', "Background hover color of options in input fields.")); export const inputActiveOptionForeground = registerColor('inputOption.activeForeground', { dark: Color.white, light: Color.black, hcDark: foreground, hcLight: foreground }, nls.localize('inputOption.activeForeground', "Foreground color of activated options in input fields."));

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:
override async setInput(newInput: GettingStartedInput, options: IEditorOptions | undefined, context: IEditorOpenContext, token: CancellationToken) { this.container.classList.remove('animatable'); this.editorInput = newInput; <del> await this.lifecycleService.when(LifecyclePhase.Restored); </del> await super.setInput(newInput, options, context, token); <ins> await this.lifecycleService.when(LifecyclePhase.Restored); </ins> await this.buildCategoriesSlide(); if (this.shouldAnimate()) { setTimeout(() => this.container.classList.add('animatable'), 0);

Discussion:
I see this in the console log when I reload vscode insiders window: <img width="1463" alt="image" src=""vscode insiders with the vscode welcome page open (I can't repro without the welcome page) window and you'll see the errors in the console logs
Change:
const href = a.getAttribute('data-href'); if (href) { if (href.startsWith(variableRefUrl)) { <del> const title = href.slice(variableRefUrl.length); </del> <ins> const title = decodeURIComponent(href.slice(variableRefUrl.length + 1)); </ins> a.parentElement!.replaceChild( this.renderResourceWidget(a.textContent!, title), a);

Discussion:
We still have the check in place to disable these in the stable build...
Can be verified by code review, or once we have a stable build.
Verifying on 0.11.1 Edit: I see the suggestion is enabled, but the behaviour is off to me. Discussing offline. Edit 2: Discussed. Marking as verified.
Change:
this.capabilities.get(TerminalCapability.CwdDetection)?.onDidChangeCwd((e) => { this._cwd = e; this._xtermOnKey?.dispose(); <del> this.refreshTabLabels(this.title, TitleEventSource.Api); </del> <ins> this.refreshTabLabels(this.title, TitleEventSource.Config); </ins> }); } }));

Discussion:
With the following settings: I'm not seeing show up: ! Changing to also doesn't show the (), but it does when I add that to description. Creating a new terminal will have it applied though: !
/verified
Change:
const onKeyDownMonaco = chain(this.searchBox.onKeyDown); onKeyDownMonaco.filter(e => e.keyCode === KeyCode.Enter).on(e => e.preventDefault(), this, this.disposables); <del> onKeyDownMonaco.filter(e => e.keyCode === KeyCode.DownArrow && e.ctrlKey).on(() => this.focusListView(), this, this.disposables); </del> <ins> onKeyDownMonaco.filter(e => e.keyCode === KeyCode.DownArrow && (isMacintosh ? e.metaKey : e.ctrlKey)).on(() => this.focusListView(), this, this.disposables); </ins> const searchChangeEvent = new Emitter<string>(); this.onSearchChange = searchChangeEvent.event;

Discussion:
We do the same for search, settings, keybindings, etc.
Attempting to do on settings (old and new) and keybindings in Insiders and not seeing anything happen. Just works, but that conflicts with the normal use of to reach the end of the input field. In Search however, works and takes you through history. Are we still in the process of moving to everywhere or are we doing something else now?
Could we maybe rename to just and use it everywhere?
On input fields that don't have history like settings and keybindings, it's just down. We could add bindings for ctrl+down for those fields too to be consistent, although I like down a lot more anyway.
I don't think it helps to have a common command for this because it's going to be different in every case.
Should extensions also be just down, given there's no history?
I think so.
Might be an issue if we want to show history in Extensions input box in future.
Note to verifier: Down arrow from the extension search box is now expected to take you to the first result
Tested on MacOS, cmd down arrow goes to end of text box instead of focusing the list
Change:
public static readonly Empty = new CodeActionKind(''); public static readonly QuickFix = new CodeActionKind('quickfix'); public static readonly Refactor = new CodeActionKind('refactor'); <del> public static readonly Extract = CodeActionKind.Refactor.append('extract'); public static readonly Convert = CodeActionKind.Refactor.append('rewrite'); </del> <ins> public static readonly RefactorExtract = CodeActionKind.Refactor.append('extract'); public static readonly RefactorInline = CodeActionKind.Refactor.append('inline'); public static readonly RefactorMove = CodeActionKind.Refactor.append('move'); public static readonly RefactorRewrite = CodeActionKind.Refactor.append('rewrite'); </ins> public static readonly Source = new CodeActionKind('source'); public static readonly SourceOrganizeImports = CodeActionKind.Source.append('organizeImports'); public static readonly SourceFixAll = CodeActionKind.Source.append('fixAll');

Discussion:
Looking into adding additional separators that are more common, so that all the additional refactorings are not just clumped under From comment: I was wondering if you would consider adding 2 code action classes that are I think quite common: (Inline) (Move) This would be super valuable for the extension that I'm developing (P42 JavaScript Assistant), but I think also for other extensions. Afaik the TS language server also has actions for example. Originally posted by in
Hey , the new code action widget looks great, and I really like the new code action grouping, I'm wondering if we can define custom code action groups besides the pre-defined groups. ! you can see the java extension contributes a code action (in the light bulb) named "add Javadoc" and it's now under "More Actions..." menu. If we can define a new group like "Sources" via extension, it would be great and more clear that we can put this action in that group.
We have an extension that publishes some code actions. With the latest VSCode, our actions are grouped under 'More Actions...' which in our context is not ideal. We would prefer to be able to define our own grouping for our actions (in extension parlance, I think this means to be able to create our own ). Thanks!
Change:
return !!(provider.capabilities & FileSystemProviderCapabilities.FileReadStream); } <del> export interface IFileSystemProviderWithFileReadCapability extends IFileSystemProvider { readFile(resource: URI): Promise<Uint8Array>; } export function hasFileReadCapability(provider: IFileSystemProvider): provider is IFileSystemProviderWithFileReadCapability { return !!(provider.capabilities & FileSystemProviderCapabilities.Readonly); } </del> export interface IFileSystemProviderWithFileAtomicReadCapability extends IFileSystemProvider { readFile(resource: URI, opts?: IFileAtomicReadOptions): Promise<Uint8Array>; }

Discussion:
Refs: I do not understand this condition: How does that make sure a method exists? The only check for this that is valid currently is , the is just a detail of the file system and not a capability.
This looks like an actual typo to me or missing code review, not sure the consequences, as it could lead to errors when wrongly asserting, so maybe moving to August for investigation.
TLDR I misunderstood how the declared capabilities relate to the actual declared methods and the meaning of . For context, this change came in through and the intention of this change was to support the scenario where an has declared but not : since is optional in the interface and the capability requires both and to be implemented: I made this change because when implementing a with but not , this would result in throwing here: I see how it's possible that a which has check does not have a method implemented. Additionally I see that we have other examples of how to handle the requirement of a readonly filesystem which implements both and , e.g.: I am reverting Apologies for the incorrect code change and thank you for pointing this out.
Change:
"scm/incomingChanges/allChanges/context": [ { "command": "git.viewAllChanges", <del> "when": "scmProvider == git && config.multiDiffEditor.experimental.enabled", </del> <ins> "when": "scmProvider == git && scmHistoryItemFileCount != 0 && config.multiDiffEditor.experimental.enabled", </ins> "group": "inline@1" } ], "scm/incomingChanges/historyItem/context": [ { "command": "git.viewCommit", <del> "when": "scmProvider == git && config.multiDiffEditor.experimental.enabled", </del> <ins> "when": "scmProvider == git && scmHistoryItemFileCount != 0 && config.multiDiffEditor.experimental.enabled", </ins> "group": "inline@1" } ],

Discussion:
Testing an empty commit Notice the action still appears even though it's a no-op. We should either hide it (preferable) or disable it. <img width="568" alt="image" src=""
Change:
@memoize get onMouseClick(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'click'), e => this.toMouseEvent(e)), e => e.index >= 0); } @memoize get onMouseDblClick(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'dblclick'), e => this.toMouseEvent(e)), e => e.index >= 0); } <ins> @memoize get onMouseMiddleClick(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'auxclick'), e => this.toMouseEvent(e)), e => e.index >= 0); } </ins> @memoize get onMouseUp(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'mouseup'), e => this.toMouseEvent(e)), e => e.index >= 0); } @memoize get onMouseDown(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'mousedown'), e => this.toMouseEvent(e)), e => e.index >= 0); } @memoize get onMouseOver(): Event<IListMouseEvent<T>> { return filterEvent(mapEvent(domEvent(this.domNode, 'mouseover'), e => this.toMouseEvent(e)), e => e.index >= 0); }

Discussion:
VSCode Version: Version: 1.27.1 (user setup) Commit: Date: 2018-09-06T09:21:18.328Z Electron: 2.0.7 Chrome: 61.0.3163.100 8.9.3 V8: 6.1.534.41 Architecture: x64 OS Version: Windows 10 Pro 64-bit (10.0, Build ) Steps to Reproduce: click item in explorer icon appear ! If you open developers tools works as expected Does this issue occur when all extensions are disabled?: Yes/No Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.478 --- <!-- score: 0.463 --<!-- potentialduplicatescomment --
Hmm strangely I am no longer getting a event when I do a middle mouse click This nicely works in stable. I see we use a different electron 2.0.9 compared to 2.0.7 but not sure if that update includes something which would influence this. Also the middle click nicely works in the tabs title area - how are you handling it there? did we change something in the tree which might effect this?
yeah see I removed  to prepare for Electron 3.0.x. We should probably wire this into the tree so that people can react to it ("onMiddleClick"). Simply forwarding the was resulting in other issues.
ok so the tree should still listen on events but bobble them up in a different way ? I can create a PR for this and you review?
yeah, the thing is, middle-click should not trigger the click, otherwise we might get wrong behaviour where people do not expect middle-click to do anything. Instead we can check clients of the tree (and list?) that want to do something on middle click and update them accordingly. Otherwise every client has to do an extra check for which mouse button was used for click.
currently the only clients of the tree that check something on middle click are explorer and quick open . For the list they are open editors view and the breakpoints view, however this still works for the breakpoints view and does not work for the open editors due to
Change:
return null; } } <ins> export class NewExplorerItem extends ExplorerItem { constructor(parent: ExplorerItem, isDirectory: boolean) { super(URI.file(''), parent, isDirectory); } } </ins>  No newline at end of file

Discussion:
Issue Type: <bBug</bExplorer asks to input file name for a new file on the wrong level after pressing <kbdEscape</kbdbutton. On the gif file below we have focus on directory, but input field created on the root level of the project. ! asks to create this issue. Related issue is Keyboard navigation: simple. Extension to switching keyboard context is installed. VS Code version: Code - Insiders 1.32.0-insider (, 2019-02-22T08:34:22.116Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (1)</summaryExtensionVersion ------ atom-keybindings3.0.6 </details<!-- generated by issue reporter --
My understanding is that this is because keyboard navigation still attempts to select the nearest file beginning with when you press , and that the “create file” action is only triggered secondary to that, so the focus has already shifted when the file is created. Super annoying.