jiebi/CodeConvo huggingface dataset:
Code change:
return; } <del> const session = await VoiceChatSessions.getInstance(instantiationService).start(controller, context); </del> <ins> session = await VoiceChatSessions.getInstance(instantiationService).start(controller, context); </ins> await holdMode; handle.dispose();

Related discussion:
text: I see this when starting the panel chat voice action in dev tools. An easy way to know when this reproduces is to enable the audio cue, which then plays forever.
<!-- 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!
Code change:
items.splice(0, 0, item); } <del> const working = repo.workingTreeGroup.resourceStates.find(r => r.resourceUri.fsPath === uri.fsPath); if (working) { const date = new Date(); const item = new GitTimelineItem('', index ? '~' : 'HEAD', localize('git.timeline.uncommitedChanges', 'Uncommitted Changes'), date.getTime(), 'working', 'git:file:working'); // TODO@eamodio: Replace with a better icon -- reflecting its status maybe? item.iconPath = new ThemeIcon('git-commit'); item.description = ''; item.setItemDetails(you, undefined, dateFormatter.format(date), Resource.getStatusText(working.type)); const cmd = this.commands.resolveTimelineOpenDiffCommand(item, uri); if (cmd) { item.command = { title: openComparison, command: cmd.command, arguments: cmd.arguments, }; } items.splice(0, 0, item); } </del> } return {

Related discussion:
text: Testing a GH/Azure Repos repository on and file, and open the timeline view that both Git and Local History entries are shown a change to the file and save Local History entry is to the top of the list Local History entry is then moved under "Uncommitted Changes" entry
Just in case: this is not specific to web version and can be reproduced in Desktop as well.
I think this works as designed: the "Uncommitted Changes" from Git is probably always updating when you save and is more recent than the actual save event. would you agree this works as intended?
Roughly as designed, but could be smoother. Maybe if we had a way to denote at an API level that an event is "current" rather than historical. Or maybe we shouldn't even have the "uncommitted changes" entry now that we have local file history.
I agree, I don't think "uncommitted changes" should be a history entry at all. It's not a historical event. You might have uncommitted changes, but itself is not a change like everything else the timeline shows. Perhaps have a "diff" action in the Timeline title instead.
I really like the idea to not have "Uncommitted Changes" at all. It seems to originate from the git extension: Especially now that we have local history enabled, there will always be an entry for local history above the last committ, so the information is redundant. Lets do this.
not sure whether we want to remove those for remotehub extension as well:
Removed the Uncommitted Changes timeline entries for RemoteHub. I kept the Staged Changes timeline entry though, since that is a historical event and it looks like we also kept those for the git extension.
Thanks!
This change has actually caught me off guard. While I like the idea for the "Local History" in general, It's sometimes too granular and I'd like to view all the changes since the last commit. Imho, the "Uncommited Changes" entry should be shown when "local history" is disabled, or it should be configurable by settings.
Can you report a new feature request for this?
Code change:
<del> { "comments": { "lineComment": "#", "blockComment": [ "#", " " ] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ], "autoClosingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ], "surroundingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ] } </del>  No newline at end of file

Related discussion:
text: VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !
Code change:
<del> { "comments": { "lineComment": "#", "blockComment": [ "#", " " ] }, "brackets": [ ["{", "}"], ["[", "]"], ["(", ")"] ], "autoClosingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ], "surroundingPairs": [ ["{", "}"], ["[", "]"], ["(", ")"], [""", """], ["'", "'"] ] } </del>  No newline at end of file

Related discussion:
text: VSCode Version: v1.2.1 OS Version: Windows 10 Steps to Reproduce: file type to INI "A=b;xxxx" in file content Expected: "b;xxxx" colored as white Actual: "b" in white but ";xxxx" in green ";xxxx" should only be regard as comments when there is no other contents in the line before ";"
This issue was moved to demyte/language-cshtml
Code change:
assert.ok(!fs.exists(service.toBackupPath(fooFile.fsPath))); assert.ok(!fs.exists(service.toBackupPath(barFile.fsPath))); <ins> // 4) backup workspace path points to a workspace that no longer exists // so it should convert the backup worspace to an empty workspace backup const fileBackups = path.join(service.toBackupPath(fooFile.fsPath), 'file'); fs.mkdirSync(service.toBackupPath(fooFile.fsPath)); fs.mkdirSync(service.toBackupPath(barFile.fsPath)); fs.mkdirSync(fileBackups); service.registerWindowForBackups(1, false, null, fooFile.fsPath); assert.equal(service.workspaceBackupPaths.length, 1); assert.equal(service.emptyWorkspaceBackupPaths.length, 0); fs.writeFileSync(path.join(fileBackups, 'backup.txt'), ''); service.loadSync(); assert.equal(service.workspaceBackupPaths.length, 0); assert.equal(service.emptyWorkspaceBackupPaths.length, 1); </ins> done(); });

Related discussion:
text: Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:
Code change:
//#endregion <del> readonly capabilities = 0; </del> <ins> readonly capabilities = WorkingCopyCapabilities.None; </ins> readonly name = basename(this.labelService.getUriLabel(this.resource));

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this &amp; IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.
Code change:
}; for (let i = 0; i < this._regions.length; i++) { const foldRange = this._regions.toFoldRange(i); <del> if (!foldRange.isUserDefined && !foldRange.isRecovered || !containedBy(foldRange)) { </del> <ins> if (!foldRange.isUserDefined && !foldRange.isRecovered || !intersects(foldRange)) { </ins> newFoldingRanges.push(foldRange); } }

Related discussion:
text: Remove Manual Folding Range doesn't work Originally posted by in select a range in the editor invoke . Selection turns into a folding range put the cursor at the beginning of the collapsed line invoke . Should remove the manual folding range
It works when the cursor is at the second column or to the right of that, but not when it's right at the beginning of the line, which is exactly where it is placed after running the create manual folding range command.
Code change:
private _findMatchesInLine(searchRegex:RegExp, text:string, lineNumber:number, deltaOffset:number, counter:number, result:EditorCommon.IEditorRange[], limitResultCount:number): number { var m:RegExpExecArray; <ins> // Reset regex to search from the beginning searchRegex.lastIndex = 0; </ins> do { m = searchRegex.exec(text); if (m) { <del> result.push(new Range(lineNumber, m.index + 1 + deltaOffset, lineNumber, m.index + 1 + m[0].length + deltaOffset)); </del> <ins> var range = new Range(lineNumber, m.index + 1 + deltaOffset, lineNumber, m.index + 1 + m[0].length + deltaOffset); // Exit early if the regex matches the same range if (range.equalsRange(result[result.length - 1])) { return counter; } result.push(range); </ins> counter++; if (counter >= limitResultCount) { return counter;

Related discussion:
text: Using regex expressions am unable to find empty lines. Tried both the end of line sequence. Copying the same text in sublime simple n finds all the blank lines.
That has been an issue for me for quite a while. Never really checked again if it's already working because I started to automatically open notepad++ again whenever I needed to replace newlines.
This problem could manifest if the lines are being split before searching as opposed to doing a full text search. Interesting side note; seems to work in find in files (Ctrl+Shift+F), just not in the find dialog (Ctrl+F).
Couldn't even find empty lines with ^$ (in case they were being split without EOL).
Looked at the code, it does indeed look at each line individually. I'm created a new issue for multi-line matching
Code change:
constructor( @IExtensionsWorkbenchService private readonly extensionsWorkbenchService: IExtensionsWorkbenchService, <del> @IPaneCompositePartService private readonly paneCompositeService: IPaneCompositePartService, </del> @IModelService private readonly modelService: IModelService, @ILanguageService private readonly languageService: ILanguageService, @IProductService productService: IProductService, <del> @INotificationService private readonly notificationService: INotificationService, @ITelemetryService private readonly telemetryService: ITelemetryService, </del> @IStorageService private readonly storageService: IStorageService, @IExtensionRecommendationNotificationService private readonly extensionRecommendationNotificationService: IExtensionRecommendationNotificationService, @IExtensionIgnoredRecommendationsService private readonly extensionIgnoredRecommendationsService: IExtensionIgnoredRecommendationsService, @IWorkspaceContextService private readonly workspaceContextService: IWorkspaceContextService, <del> @IExtensionManagementServerService private readonly extensionManagementServerService: IExtensionManagementServerService, </del> ) { super(); this.fileOpenRecommendations = {};

Related discussion:
text: When a user opens a file extension that does not have a specific recommendation tied to it, we show the general notification that points users to the marketplace. This has the following flaws: Most popular file types are already covered by specific extensions, so what gets left in this experience is leftovers For most of the extensions there is no good extension to handle this experience. Thus opening the Extension page does not provide value This is adding un-needed pings to the Marketplace service Also we had a bug that this feature was not available in stable and only 3 users found it is not there Would love for us to get some telemetry on this actions to see if this is actually bringing value to users. If not, we should either: Remove this flow completely Have a pre-defined set of file extensions for which we show this. Checking with tags seems to be very faulty. In my example below there is not an extension that helps with PowerPoint files. !
Only of these notifications end up with users clicking on Search Marketplace ! When it is actually clicked here are the top extensions ! Thus I suggest that we: Remove this dialog Add explicit extension recommendation for and . Since those seem to be missing. what do you think?
Sounds good to me
Great. Ok, you remove the dialog when you find time, I will add the recommendations for csv and pdf. Or if you go on vacation, I can also remove the dialog. I am working in August. Thanks
Feel free to remove it in August, otherwise I can also do it in September. Here it is
To verify: a file with some strange extension. For example -make sure no notification shows up a .py file or .go file. Make sure you get an extension recommendation for specific python / go extensions
Code change:
} } } <ins> KeybindingsRegistry.registerKeybindingRule({ id: 'undo', weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.LeftArrow, when: ContextKeyExpr.and(EditorContextKeys.writable, ContextKeyExpr.or(GhostTextController.inlineSuggestionVisible, GhostTextController.inlineSuggestionJustCommitted)), }); </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:
} } } <ins> KeybindingsRegistry.registerKeybindingRule({ id: 'undo', weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.LeftArrow, when: ContextKeyExpr.and(EditorContextKeys.writable, ContextKeyExpr.or(GhostTextController.inlineSuggestionVisible, GhostTextController.inlineSuggestionJustCommitted)), }); </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:
} } } <ins> KeybindingsRegistry.registerKeybindingRule({ id: 'undo', weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.LeftArrow, when: ContextKeyExpr.and(EditorContextKeys.writable, ContextKeyExpr.or(GhostTextController.inlineSuggestionVisible, GhostTextController.inlineSuggestionJustCommitted)), }); </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:
} } } <ins> KeybindingsRegistry.registerKeybindingRule({ id: 'undo', weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.LeftArrow, when: ContextKeyExpr.and(EditorContextKeys.writable, ContextKeyExpr.or(GhostTextController.inlineSuggestionVisible, GhostTextController.inlineSuggestionJustCommitted)), }); </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