Question: 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 {

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.


Question: 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 {

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.


Question: 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 {

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.


Question: 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),

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.


Question: } 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 {

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=""