jiebi/CodeConvo huggingface dataset:
Code change:
import { onUnexpectedError, isPromiseCanceledError } from 'vs/base/common/errors'; import { IWindowService } from 'vs/platform/windows/common/windows'; import { TPromise } from 'vs/base/common/winjs.base'; <del> import { IWorkspaceContextService } from 'vs/platform/workspace/common/workspace'; </del> <ins> import { IWorkspaceContextService, WorkbenchState } from 'vs/platform/workspace/common/workspace'; </ins> import { IConfigurationService, ConfigurationTarget } from 'vs/platform/configuration/common/configuration'; import { localize } from 'vs/nls'; import { Action } from 'vs/base/common/actions';

Related discussion:
text: When you open a recent project from the welcome screen, the last one remains opened in a tab. VSCode Version: 1.9.1 OS Version: macOS Sierra 10.12.3 Steps to Reproduce: a new VSCode window. a recent project from the welcome screen. project is opened and the welcome screen remains opened.
The current behavior was chosen in the hope that this would help new users by staying in the same context.
I agree that the welcome screen should be closed after taking an action from it. Especially in my case, where I prefer to use the setting, having to close the otherwise empty welcome window after opening from the 'Recents' list or via FileOpen feels like a bug.
You can just not show it at all. Or do you need any of the actions on it? (I'm trying to preserve the new user experience here which relies much more on guidance.)
It's ok showing the welcome screen, but it should be closed after opening a project from there.
With we change the Welcome editor to open in preview mode, this way it will close when the next editor opens. (If preview mode is not disabled in settings.)
This could be an additional value for the setting.
Hey, I could look into this. Got any tips on where I should start ?
Great: Add an additional enum literal here: Check for that literal and the 'open folder' condition here:
Hey , I've ran into some questions which you might be able to help me with: should I name the enum literal? I can't seem to come up with the right name would I check for the 'open folder' condition?
You could use . Check for no folder being open: . You can get at the context service by adding it to the constructor of the calling class, similar to:
Hey everything seems to be working now, just one last question which is confusing me: isn't the objective of this issue to NOT show the Welcome Page when opening a new project? So why is your enum suggestion welcomePageInEmptyWorkbench? What is happening right now after my additions is: upon opening a new project, no Welcome Page is shown. Is this right?
Show it only in the empty workbench. :)
Hey Now I'm getting upon opening a new window (empty workbench). Any ideas? I did the comparison as you said for no folder being open.
Is the ?
Code change:
import { onUnexpectedError, isPromiseCanceledError } from 'vs/base/common/errors'; import { IWindowService } from 'vs/platform/windows/common/windows'; import { TPromise } from 'vs/base/common/winjs.base'; <del> import { IWorkspaceContextService } from 'vs/platform/workspace/common/workspace'; </del> <ins> import { IWorkspaceContextService, WorkbenchState } from 'vs/platform/workspace/common/workspace'; </ins> import { IConfigurationService, ConfigurationTarget } from 'vs/platform/configuration/common/configuration'; import { localize } from 'vs/nls'; import { Action } from 'vs/base/common/actions';

Related discussion:
text: You can debug it either in VS Code or in the Developer Tools (Help Toggle Developer Tools in the window running from source).
Upon opening a new window, it isn't undefined (verified by a console log) but then it turns undefined (verified by the same console log). Edit: and immediately after Edit2: Found it! Seems like isWelcomePageEnabled() is called twice, once in the class constructor and the other one in the onReady method. I'll make the PR in a bit
Code change:
isExtensionOwnedTerminal?: boolean; useShellEnvironment?: boolean; location?: TerminalLocation | { viewColumn: number, preserveFocus?: boolean } | { parentTerminal: ExtHostTerminalIdentifier } | { splitActiveTerminal: boolean }; <ins> disablePersistence?: boolean; </ins> } export interface MainThreadTerminalServiceShape extends IDisposable {

Related discussion:
text: Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is
Code change:
import { registerIcon } from 'vs/platform/theme/common/iconRegistry'; import { UntitledTextEditorInputSerializer, UntitledTextEditorWorkingCopyEditorHandler } from 'vs/workbench/services/untitled/common/untitledTextEditorHandler'; import { DynamicEditorConfigurations } from 'vs/workbench/browser/parts/editor/editorConfiguration'; <del> import { EditorActionsDefaultAction, EditorActionsTitleBarAction, HideEditorActionsAction, HideEditorTabsAction, ShowMultipleEditorTabsAction, ShowSingleEditorTabAction, ZenHideEditorTabsAction, ZenShowMultipleEditorTabsAction, ZenShowSingleEditorTabAction } from 'vs/workbench/browser/actions/layoutActions'; </del> <ins> import { ConfigureEditorAction, ConfigureEditorTabsAction, EditorActionsDefaultAction, EditorActionsTitleBarAction, HideEditorActionsAction, HideEditorTabsAction, ShowMultipleEditorTabsAction, ShowSingleEditorTabAction, ZenHideEditorTabsAction, ZenShowMultipleEditorTabsAction, ZenShowSingleEditorTabAction } from 'vs/workbench/browser/actions/layoutActions'; </ins> import { ICommandAction } from 'vs/platform/action/common/action'; import { EditorContextKeys } from 'vs/editor/common/editorContextKeys';

Related discussion:
text: ! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings
Code change:
sortedIndexes.push(this.sortedIndexes[i++] + diff); } <del> const length = this.length + diff; if (this.sortedIndexes.length > 0 && sortedIndexes.length === 0 && length > 0) { const first = this.sortedIndexes.find(index => index >= start) ?? length - 1; sortedIndexes.push(Math.min(first, length - 1)); } </del> this.renderer.splice(start, deleteCount, elements.length); this._set(sortedIndexes, sortedIndexes); <del> this.length = length; </del> } renderIndex(index: number, container: HTMLElement): void {

Related discussion:
text: Type: <bBug</bWhen pressing to collapse all nodes in a list view it leaves selection in such a state that you cannot expand nodes with until you do something to change the selection. ! I believe what's happening is is leaving the originally selected node selected. So after executing the command you end up with 2 selections, your original selection plus the last root node in the list. The original selection is the primary selection, and if it has no children does not have anything to expand and is a no-op. As a user it looks like you have the root node selected, which has children to expand, but pressing does nothing. Pressing then expands the list to reveal your original selection and you see that you unexpectedly have multiple selections. The current behavior of appears to be: Leave the originally selected node selected Add a second selection to the last root node in the list The expected behavior here is: Move selection to the root node of your currently selected node Ideally this also retains multiple selection: each selection is moved to the root node of that selection. VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looking at this again in the File Explorer it looks like the selection highlight is left on the where the original selection was despite the fact that the node is now in a different position. However, the "real" selection is still on the node. This means it looks like one thing is highlighted and pressing opens a different thing.
Just submitted a PR for this. Could you please review it?
What is the behavior supposed to be? Here's what I see: keyboard to focus a tree node that has a parent to collapse all moves to the whole tree and arrow down takes me to the first tree element. Right arrow does nothing.
The current behavior sort-of fixes the issue, insofar as is dodges it by doing something less desirable - moves selection to the whole tree. Imo, selection should remain on the root node(s) of whichever tree branch selection is currently in.
Code change:
sortedIndexes.push(this.sortedIndexes[i++] + diff); } <del> const length = this.length + diff; if (this.sortedIndexes.length > 0 && sortedIndexes.length === 0 && length > 0) { const first = this.sortedIndexes.find(index => index >= start) ?? length - 1; sortedIndexes.push(Math.min(first, length - 1)); } </del> this.renderer.splice(start, deleteCount, elements.length); this._set(sortedIndexes, sortedIndexes); <del> this.length = length; </del> } renderIndex(index: number, container: HTMLElement): void {

Related discussion:
text: I think this is what the previous behavior was trying to do, it just had an issue with leaving selection in a bad state. A couple examples ([x] denotes current selection): Start state End state, after Stat state End state
I agree, feel free to send an issue for it. Your observations are the fixed state. Here's the entire story: Marking it as verified.
Code change:
sortedIndexes.push(this.sortedIndexes[i++] + diff); } <del> const length = this.length + diff; if (this.sortedIndexes.length > 0 && sortedIndexes.length === 0 && length > 0) { const first = this.sortedIndexes.find(index => index >= start) ?? length - 1; sortedIndexes.push(Math.min(first, length - 1)); } </del> this.renderer.splice(start, deleteCount, elements.length); this._set(sortedIndexes, sortedIndexes); <del> this.length = length; </del> } renderIndex(index: number, container: HTMLElement): void {

Related discussion:
text: Testing focus on trusted URI list of items tab to navigate to the X to remove an item. Press to trigger removal nicely gets removed from the list, however focus is lost Focus should be preserved in the list on the neighbour item (example: checkout how Explorer does that when deleting a file). I thought this would be tackled via
The trust editor does a lot of full page re-rendering which I should improve (remove) so I doubt this is an issue with the table widget itself.
Code change:
provideRefactorNotApplicableReason: true, generateReturnInDocTemplate: config.get<boolean>('suggest.jsdoc.generateReturns', true), includeCompletionsForImportStatements: config.get<boolean>('suggest.includeCompletionsForImportStatements', true), <del> includeCompletionsWithSnippetText: config.get<boolean>('suggest.includeCompletionsWithSnippetText', true), </del> <ins> includeCompletionsWithSnippetText: true, </ins> includeCompletionsWithClassMemberSnippets: config.get<boolean>('suggest.classMemberSnippets.enabled', true), includeCompletionsWithObjectLiteralMethodSnippets: config.get<boolean>('suggest.objectLiteralMethodSnippets.enabled', true), autoImportFileExcludePatterns: this.getAutoImportFileExcludePatternsPreference(preferencesConfig, vscode.workspace.getWorkspaceFolder(document.uri)?.uri),

Related discussion:
text: Request completions, commit on Expected: Regular completion, no method body OR completion that is otherwise identical to both settings being . Actual
I want to understand this better, since this kind of behavior is also present in other completions I think: how should interact with completions that can or cannot contain snippets? For instance, the class member completion can be a snippet, but it doesn't necessarily have to be, which is why it still shows up in the example above when is false, but the difference is that it's no longer a snippet (i.e. there's no tab stop in the body of the completed method). I guess this bug is saying that this completion should never be offered in its non-snippet form? Is this the case because not having the tab stop in the method's body degrades the user experience? Is it because of some other reason?
Ugh - okay, so there's plain completions completions with insert text completions with tab stops and for some reason, is the one that enables tab stops. Did I get that right?
I think so, yes. Not sure if this this is relevant, but note that while is a setting that is user-configurable in vscode, while is not. Andrew B once told me that's because is supposed to indicate whether an editor supports insert text in completions or not.
I believe it's controlled by setting
and say that this should never have been user-visible in the first place. The flag shouldn't have been passed in as-is to TypeScript. If anything, the editor should use a flag like to blanket enable/disable other snippet features.
I don't see the removed setting anymore so marking as verified.
Code change:
} export interface Stash { <del> index: number; description: string; branchName?: string; </del> <ins> readonly hash: string; readonly parents: string[]; readonly index: number; readonly description: string; readonly branchName?: string; </ins> } interface MutableRemote extends Remote {

Related discussion:
text: a new file with the following content and commit it. the file to like as follows, save it, and create a stash with it the file to like as follows, and save it the "Git: View Stash..." command and pick the created stash diff in the stash should look as follows: <img width="921" alt="image" src=""