jiebi/CodeConvo huggingface dataset:
Code change:
return; } <del> const root = element instanceof SearchResult ? null : element; this.tree.setChildren(root, this.createIterator(element, collapseResults)); </del> <ins> if (element instanceof SearchResult) { this.tree.setChildren(null, this.createIterator(element, collapseResults)); } else { this.tree.setChildren(element, this.createIterator(element, collapseResults)); this.tree.rerender(element); } </ins> }); } }

Related discussion:
text: I do not see a duplicate of my issue: ! So I'm in the clear. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.32.0 OS Version: Windows 10 1809 Stable Steps to Reproduce: Visual Studio Code, click on the "Search" sidebar menu item to bring up the huge Search menu. ! for a common word used quite a lot. Like "a", "let", "var", "i", and so forth. the Search displays the total results count, dismiss a few of them. total results count should decrement by 1 per dismissal, or indicate both the original total results count and the remaining non-dismissed total results count side by side when dismissing the search results. For example: ! Does this issue occur when all extensions are disabled?: Yes
For me, it does decrement. You don't see that? You are clicking the 'x' icon on a result row, right?
It doesn't. !
Ok, so I was about to get it to decrement, but that's not done in real-time. ! Both of the GIFs are done in 1.32.1.
That's right, I thought you were talking about the total shown at the top ("x results in y files") in your original post.
This also happens when a new match is or deleted in an existing file match. !
Code change:
id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

Related discussion:
text: <!-- 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. --When using Copilot, users would like to be able to only partially accept suggestion instead of the whole suggestion at once. The users demand either word by word or line by line completion. Desired behaviour: Press a predefined key and accept the whole suggestion. Use a predefined combination of 2 keys to accept the top line of the suggestion. (eg: For a suggestion of 3 lines, the user would need to press the combination 3 times to accept the whole suggestion). The prompt would not show the line already accepted.
this sounds to me like a UX problem. Is there a mock sketch for a potential solution here? Is there some other editor which already supports this? We can also discuss it in one of our UX weekly meetings.
I don’t have a mock sketch. No other editors are supporting this yet but it is a requested features. I wanted to get the discussion going (doing the same for the other editors) to understand the constraints around it as well.
Technically, I think this would be rather easy to implement. I'd love to hear some more UX discussion before we implement this thought. What key-binding do you have in mind?
do you have some UX designers on your team that would like to help here? Once we have some good ux proposal we can bring it in our UX weekly sync on Wednesday to start the discussion.
No I dont have a UX designer in my team. I ll see how i can come up with a suggestion and get back to you
This is similar to Solution for me was 'CMD + -' to accept a word at a time. Something similar here would be great.
Fish shell allows word-by-word completion using the <kbdAlt</kbd+ <kbd&;</kbdkey-combo, which—at least on macOS—is used system-wide for navigating text word-by-word. I notice that I keep trying to automatically use this key-combo, so big +1 from me. ( Did not realise this is the vscode repo.) 
awesome idea. since you said this is low hanging maybe we assign to July for the initial investigation? What do you think?
This would be great.
Code change:
id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

Related discussion:
text: I am loving copilot so far, but this is my biggest UX gripe. Copilot's first suggestions in a new piece of code tend to only be accurate for the first few words. It tends to get much better only after more context is . Not a blocker, but it'd make it much easier to get started.
We did an initial investigation and this is not low hanging as I have initially commented above. Also, this milestone we have been mostly focusing on improving the merge editor. So this one will have to continue in September.
Had a sync with the VS folk and here's some very early thinking: When partial completion is accepted the ghost text should not change - we should use the cache. VS did multiple user studies and users always get shocked when the ghost text changes beneath them Undo is the user gesture to undo the last partial acceptance (this should work out of the box for us). Simple keybindings like word next navigation, and navigate to end of line should be used for partial word acceptance, and whole line acceptance. So same keybindnigs as and commands. Open questions (probably not for first version): How to make this keybindings discoverable Should we support the mouse? For example alt + mouse click to accept until the mouse click
I've also previously advocated for a way to accept only a single line out of the multi-line completion. I would strongly support doing this at a line granularity, rather than e.g. token granularity, since I ~never run into the case where I want to accept 'more than 0 tokens but less than a line' of a multi-line completion -- it's ~always either one line or maybe a couple, or the whole completion. Repurposing regular cursor movement commands for partial acceptance when a ghost text completion is open sounds error-prone. I see this kind of key-stealing behavior in some autocomplete systems (especially for ), but it's always optional, since it's really easy to interfere with muscle memory and frustrate people. This would apply to text navigation commands for sure, and it would be even worse in the middle-of-the-line completion case (which would also be wonky if we want an 'accept a single token' shortcut).
Hi! A use case for per-word completion: comment/natural language completion. I want this almost every time that copilot gives me a comment suggestion.
Code change:
id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

Related discussion:
text: To make sure I understand the shape of the discussion, I think three issues are separable here: 1) whether to offer partial completion; 2) at what granularities (here the use case and example-based analysis is most relevant, and feed back into question 1); 3) if doing it, what default keybindings at these levels to provide so as not to hijack muscle memory (but possibly still utilize it in a parallel modifier key universe)? Is that right, and if so at what stage does the team currently see the conversation? For 3), in Lisp-y language tools, Paredit's keybindings might be a decent template too: in some sense what we are doing here is structurally selecting part of what is an (falling back on a as above) structure before "acceptance" (which is already well-understood as a result of by default keybinding users). That would be a more elaborate form of the partial acceptance, though, requiring a language-sensitive parse, so definitely not low hanging fruit.
It's a marketing problem, they market the code you accept as efficiency. If they would also add the 97% of the code you have to remove carefully again it wouldn't be that a nice metric. I believe we need to adapt the plugins on our own or write a plugin watchdog, something that monitors completions, immediately removes them and offers a word-by-word insert of the code.
A use case from He wants to accept the first couple of words here (but not the entire completion): ! ... ~~ A use case for line based acceptance: !
For jetbrains IDE's you can use my plugin () You press CTRL+ALT+D and it will complete the sentence word by word. So in your example you press it 3 times (you'll be after "to", then you type "have a per" and you can continue with the shortcut 3 more times on the new completion text. Or just "TAB" if all is good after your intervention, it doesn't block you from using the default behavior of copilot Though the plugin only works on IntelliJ IDE's (you need to install 'LivePlugin' and 'Stewardess')
I love this suggestion. I encounter the scenario of wanting to only accept a suggestion partially a lot.
would you prefer word-by-word partial acceptance or line-by-line?
Code change:
id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: EditorContextKeys.writable </del> <ins> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </ins> }); }

Related discussion:
text: It would be awesome to be able to do both, but if only one of the two is possible, then I would prefer word-by-word.
There is no reason why only one would be doable. A line based completion is a couple of lines of code. Word based completion is half a page if you want to do the word separation smart, or an abstract if it's dumb.
First iteration has been implemented in
Code change:
{ "scope": "markup.heading", "settings": { <ins> "fontStyle": "bold", </ins> "foreground": "#6796e6" } },

Related discussion:
text: <!-- 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. --This is essentially a more general issue of the closed Markdown styling support are missing in the following, missing bold and italic: Solarized Light Red Abyss Solarized Dark Tomrrow Night Blue See screenshot below for an example. For High Contrast, section heading () are not in bold. I am unclear if it's a bug or intentional. Screenshot for Solarized Dark !
Hi, I tried bold and italic with these themes: theme-tomorrow-night-blue theme-solarized-dark theme-solarized-light theme-red theme-kimbie-dark theme-abyss hcblackdefaults(High Contrast)
Code change:
*/ toString(skipEncoding?: boolean): string; toJSON(): UriComponents; <ins> /** * A helper function to revive URIs. * * **Note** that this function should only be used when receiving Uri#toJSON generated data * and that it doesn't do any validation. Use {@link Uri.from} when received "untrusted" * uri components such as command arguments or data from storage. * * @param data The Uri components or Uri to revive. * @returns The revived Uri or undefined or null. */ </ins> static revive(data: UriComponents | Uri): Uri; static revive(data: UriComponents | Uri | undefined): Uri | undefined; static revive(data: UriComponents | Uri | null): Uri | null;

Related discussion:
text: Following test throws: I found this while investigating At that point the editor component is quite broken because of a lot of errors being thrown. Notice how not even a tab shows for the editor: <img width="1058" alt="image" src="https://user-"
that should already throw because at least a scheme is needed. It doesn't because was designed to be the runtime counter part of which never produces such output so some IPC deserialisation cost can be saved.
, that works for me and will also throw when we get bad objects into such as the from
Yeah, my plan is to add an argument like we have in other URI-places. It will default to true and only IPC should be relaxed
Not doing that because it actually already exists as . I believe the adoption/migration task is to use instead of whenever getting uri components from storage or esp from command arguments. Tho, there is one special case for which is that it automatically uses when the scheme is missing. We could make that configurable but a check for might make this obsolete
Closing this after and the ask to use when creating uri from "untrusted" sources
I will see to adopt , I forgot we had it
Code change:
isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

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:
isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

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:
isItemVisible(item: ExplorerItem): boolean; isItemCollapsed(item: ExplorerItem): boolean; hasFocus(): boolean; <ins> getFocus(): ExplorerItem[]; focusNext(): void; focusLast(): void; </ins> } function getFocus(listService: IListService): unknown | undefined {

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:
export async function getInlayHints(model: ITextModel, ranges: Range[], token: CancellationToken): Promise<InlayHintsData[]> { const datas: InlayHintsData[] = []; const providers = InlayHintsProviderRegistry.ordered(model).reverse(); <del> const promises = flatten(providers.map(provider => ranges.map(range => Promise.resolve(provider.provideInlayHints(model, range, token)).then(result => { if (result) { datas.push({ list: result, provider }); } }, err => { onUnexpectedExternalError(err); })))); </del> <ins> const promises = flatten(providers.map(provider => ranges.map(range => { return Promise.resolve(provider.provideInlayHints(model, range, token)).then(result => { const itemsInRange = result?.filter(hint => range.containsPosition(hint.position)); if (itemsInRange?.length) { datas.push({ list: itemsInRange, provider }); } }, err => { onUnexpectedExternalError(err); }); }))); </ins> await Promise.all(promises);

Related discussion:
text: Issue Type: <bBug</bRelated to and Steps to reproduce: and or corresponding JS settings. Create new TS or JS file and paste next code: and ! TS Version 4.4.0-dev. VS Code version: Code - Insiders 1.59.0-insider (, 2021-07-28T05:13:47.114Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/assign
/ Can you please take a look? I believe that folding generates two new requests for inlay hints that VS Code then displays incorrectly. Here's the TS server trace from folding with only : The position of the hints seem correct to me. I don't know why VS Code requests the hints twice here though (or why it needs to re-request any hints on folding in this case since no new code became visible)
These are the visible ranges: ! And vscode sends two requests, one for each range. For some reason, each reuqest returns one inlay hint, so in total, there are 2 inlay hints: ! do you have an idea why this is? To me, it looks like a bug in the provider, there should not be a result for the second request.
Emmmmmm... I think I know the reason. In the tsserver. For each request, we will get the hint in the area that overlay with the visible range (not strictly included). Honestly, I don't know about this behavior. We may could de-duplicate these items?
Can't you just filter out all inlay hints whose position is not in the requested range?
Well, do you prefer to do it in vscode or ts side?
Hmm, maybe actually in vscode.
Verified fixed with TypeScript Nightly in
Code change:
box-shadow: none; } <ins> .hc-black .monaco-menu .monaco-action-bar.vertical .action-item { border: 1px solid transparent; /* prevents jumpig behaviour on hover or focus */ } </ins> .hc-black .monaco-menu .monaco-action-bar.vertical .action-item.focused { background: none; border: 1px dotted #f38518;

Related discussion:
text: Refs: Steps: enter high contrast theme hover over menu items they jump up and down while doing that
Code change:
return this.shouldShowCompositeBar() ? super.getVisiblePaneCompositeIds() : this.acitivityBarPart.getVisiblePaneCompositeIds(); } <del> focusActivityBar(): void { </del> <ins> async focusActivityBar(): Promise<void> { if (this.configurationService.getValue(LayoutSettings.ACTIVITY_BAR_LOCATION) === ActivityBarPosition.HIDDEN) { await this.configurationService.updateValue(LayoutSettings.ACTIVITY_BAR_LOCATION, this.getRememberedActivityBarVisiblePosition()); this.onDidChangeActivityBarLocation(); } </ins> if (this.shouldShowCompositeBar()) { this.focusComositeBar(); } else { if (!this.layoutService.isVisible(Parts.ACTIVITYBAR_PART)) { this.layoutService.setPartHidden(false, Parts.ACTIVITYBAR_PART); } <del> this.acitivityBarPart.focus(); </del> <ins> this.acitivityBarPart.show(true); </ins> } }

Related discussion:
text: Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!
Code change:
import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; import { IStorageService } from 'vs/platform/storage/common/storage'; import { IThemeService } from 'vs/platform/theme/common/themeService'; <del> import { hasCustomTitlebar } from 'vs/platform/window/common/window'; </del> <ins> import { hasNativeTitlebar } from 'vs/platform/window/common/window'; </ins> import { IEditorGroupView, IEditorPartsView } from 'vs/workbench/browser/parts/editor/editor'; import { EditorPart, IEditorPartUIState } from 'vs/workbench/browser/parts/editor/editorPart'; import { IAuxiliaryTitlebarPart } from 'vs/workbench/browser/parts/titlebar/titlebarPart';

Related discussion:
text: Verification set to enable native title bar in settings open a floating window ensure you see no custom title below the native title