jiebi/CodeConvo huggingface dataset:
Code change:
import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as platform from 'vs/base/common/platform'; import { MenuRegistry } from 'vs/platform/actions/common/actions'; <ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; </ins> // sticky suggest widget which doesn't disappear on focus out and such let _sticky = false;

Related discussion:
text: When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.
Code change:
import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as platform from 'vs/base/common/platform'; import { MenuRegistry } from 'vs/platform/actions/common/actions'; <ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; </ins> // sticky suggest widget which doesn't disappear on focus out and such let _sticky = false;

Related discussion:
text: I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.
Code change:
import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as platform from 'vs/base/common/platform'; import { MenuRegistry } from 'vs/platform/actions/common/actions'; <ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; </ins> // sticky suggest widget which doesn't disappear on focus out and such let _sticky = false;

Related discussion:
text: Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.
Code change:
import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as platform from 'vs/base/common/platform'; import { MenuRegistry } from 'vs/platform/actions/common/actions'; <ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; </ins> // sticky suggest widget which doesn't disappear on focus out and such let _sticky = false;

Related discussion:
text: so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected
Code change:
if (highlights) { return { label, <del> description: getStateLabel(session.state), </del> highlights: { label: highlights }, accept: (keyMod, event) => { this._debugService.focusStackFrame(undefined, undefined, session, { explicit: true });

Related discussion:
text: Testing !
I just noticed that is not localized and is not meant for display. That means that "Label" was not a good name for that function, but we can either just remove the state or find the code that drives the state label in the callstack.
Actually, it seems that only displays , , or , which is probably not super useful to the user anyways. It seems like the info like is only available on each thread, and a debug session can have multiple threads. Perhaps we should just remove the state for now.
Code change:
private _shouldFocus: boolean; private _colorPicker: ColorPickerWidget | null; private _renderDisposable: IDisposable | null; <ins> private _preferBelow: boolean; </ins> constructor( editor: ICodeEditor,

Related discussion:
text: Issue Type: <bFeature Request</bI want the message could display under the variables it refers to. Because the message box blocks the code over the current line. Thank you. VS Code version: Code 1.36.1 (, 2019-07-08T22:59:35.033Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Can we just change the default to or does this require a setting?
Kind of feel like this is out of scope, but I don't think this should be assigned to me since it's regarding monaco.
Actually I was wrong - it is determined by : I verified if I swap the order then the hovers appear below instead of above (where there's space). I'll make a PR.
Done! Before: <img width="734" alt="Screenshot 2021-06-30 at 08 45 06" src="https://user-"Change the setting: <img width="921" alt="Screenshot 2021-06-30 at 08 45 14" src="https://user-"After: <img width="777" alt="Screenshot 2021-06-30 at 08 45 22" src="https://user-"
Let's continue tracking in
Code change:
import { ICommandService } from 'vs/platform/commands/common/commands'; import { ContextKeyExpr, ContextKeyExpression, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; import { Disposable } from 'vs/base/common/lifecycle'; <del> import { IUserDataSyncEnablementService } from 'vs/platform/userDataSync/common/userDataSync'; </del> <ins> import { EXTENSIONS_SYNC_CONTEXT_KEY, IUserDataSyncEnablementService } from 'vs/platform/userDataSync/common/userDataSync'; </ins> import { IExtensionDescription } from 'vs/platform/extensions/common/extensions'; import { URI } from 'vs/base/common/uri'; import { joinPath } from 'vs/base/common/resources';

Related discussion:
text: I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).
Code change:
} // Save selection <del> const selection = this.widget?.getSelection(); </del> <ins> const selection = new Set<Marker>(); for (const marker of this.widget.getSelection()) { if (marker instanceof ResourceMarkers) { marker.markers.forEach(m => selection.add(m)); } else if (marker instanceof Marker || marker instanceof MarkerTableItem) { selection.add(marker); } } // Save focus const focus = new Set<Marker>(); for (const marker of this.widget.getFocus()) { if (marker instanceof Marker || marker instanceof MarkerTableItem) { focus.add(marker); } } </ins> // Create new widget this.createWidget(this.widgetContainer); this.refreshPanel(); // Restore selection <del> if (selection && selection.length > 0 && (selection[0] instanceof Marker || selection[0] instanceof MarkerTableItem)) { </del> <ins> if (selection.size > 0) { this.widget.setMarkerSelection(Array.from(selection), Array.from(focus)); </ins> this.widget.domFocus(); <del> this.widget.setMarkerSelection(selection[0]); </del> } }

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
iconClass: ThemeIcon.asClassName(searchOpenInFileIcon), tooltip: localize('QuickSearchOpenInFile', "Open File") }], <ins> trigger: async (): Promise<TriggerAction> => { await this.handleAccept(fileMatch, {}); return TriggerAction.CLOSE_PICKER; }, </ins> }); const results: Match[] = fileMatch.matches() ?? [];

Related discussion:
text: ! quick search. over a file name pick item and click the button to open the file. happens :bug:
Code change:
"filenames": [ "git-rebase-todo" ], <ins> "filenamePatterns": [ "**/rebase-merge/done" ], </ins> "configuration": "./languages/git-rebase.language-configuration.json" }, {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Do not see similar issues here: Steps to Reproduce: interactive rebase click tab, "Copy path" file picker, paste path path file name from to . This is a file that git uses to track what is done. "Language mode" should be "Git Rebase Message" but it is not. I am using worktrees, but I don't think this is related, since has proper language detection.
Code 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)); </ins> a.parentElement!.replaceChild( renderResourceWidget(a.textContent!, title), a);

Related discussion:
text: <img width="377" alt="image" src=""
Verification step- just use a variable in a multiroot workspace, and check that you have the right blue background when it's rendered in the request.
Works great. Slightly related - why do we just render the blue background while I am typing the request, but do not render it blue when the request is sent. This was always the behaviour and is unrelated to MR workspace. I am just curious !
If it was used correctly, it will have the blue background. Did you pick the file from the picker, or just type the text?
Picked from file picker.
Oh no!
Apparently I didn't test this as thoroughly as I should have. Some files now break the markdown link. Need to rework this in main for debt week but there is an easy fix for now.
For verification, we should test with Files in a multiroot workspace In single folder window Files at the top level of the workspace And under a folder
Since the PR has been merged yesterday, this issue will be closed, for verification.
Code change:
const content = model.main; if (!input.resource.path.endsWith('.md')) { <del> safeInnerHtml(this.content, content); </del> <ins> safeInnerHtml(this.content, content, { ALLOW_UNKNOWN_PROTOCOLS: true }); </ins> this.updateSizeClasses(); this.decorateContent();

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.93.0-insider (user setup) Commit: Date: 2024-09-04T13:13:15.344Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0. OS Version: Windows 11 Insiders Steps to Reproduce: in the first paragraph doesn't appear to be a link, which I was surprised about: ! I hover over it, I see it's supposed to be a link, but clicking on it does nothing: ! The other docs links at the bottom of the playground appear correctly as links and do open when I click on them: !
This seems related to the bookmark issue we had in the release notes. The other bookmark links in the interactive playground don't work either.
Fixed the toc links. Need another fix for the documentation link too (which use command uris)
The Editor Playground is not showing at all anymore in the latest insiders. When selecting the Editor Playground menu item, a black editor comes up.
hm working from oss builds. Insiders, it seems like the error is:
Actually unrelated. Seems like a duplicate of and fixed by
Code change:
<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M12.632,8A4.632,4.632,0,1,1,8,3.368,4.638,4.638,0,0,1,12.632,8Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4.211A3.789,3.789,0,1,0,11.789,8,3.788,3.788,0,0,0,8,4.211ZM8,10.79A2.79,2.79,0,1,1,10.79,8,2.794,2.794,0,0,1,8,10.79Z"/></g></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M12.632,8A4.632,4.632,0,1,1,8,3.368,4.638,4.638,0,0,1,12.632,8Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4.211A3.789,3.789,0,1,0,11.79,8,3.788,3.788,0,0,0,8,4.211ZM8,10.29A2.29,2.29,0,1,1,10.29,8,2.292,2.292,0,0,1,8,10.29Z"/></g></svg> </ins>  No newline at end of file

Related discussion:
text: When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !
Code change:
}); } exports.config = { <del> version: product.electronRepository ? '22.4.5' : util.getElectronVersion(), </del> <ins> version: product.electronRepository ? '22.4.6' : util.getElectronVersion(), </ins> productAppName: product.nameLong, companyName: 'Microsoft Corporation', copyright: 'Copyright (C) 2023 Microsoft. All rights reserved',

Related discussion:
text: This works on web e.g. but does not work in desktop, either with a desktop git clone or with RemoteHub. The last time this happened it was due to a regression in the list of enabled codecs for our Electron builds.
Sorry for the breakage, the changes from has not been to Electron = 22 versions yet. It will be addressed in new builds this week.
Addressed in
Reopening because of
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@22.3.5: version "22.3.5" resolved "https://registry.yarnpkg.com/electron/-/electron-22.3.5.tgz#a53a318cbb25a44914dfedd30a9ad6120632197f" integrity sha512-CTdnoTbO3sDiMv47TX3ZO640Ca57v1qpiqGChFF8oZbtfHuQjTPPaE4hsoynf22wwnBiyJNL41DpB/pfp9USnA== </del> <ins> electron@22.3.6: version "22.3.6" resolved "https://registry.yarnpkg.com/electron/-/electron-22.3.6.tgz#ab79a2da20e83b02ec9cbb22a4069468e6949b4f" integrity sha512-/1/DivFHH5AWa/uOuqpkeg12/jjicjkBU8kYv70oeqRFwXzoyuJhgwlzER4jZXnbGjF5Nxz9900oXq/QzAViAw== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^16.11.26"

Related discussion:
text: This works on web e.g. but does not work in desktop, either with a desktop git clone or with RemoteHub. The last time this happened it was due to a regression in the list of enabled codecs for our Electron builds.
Sorry for the breakage, the changes from has not been to Electron = 22 versions yet. It will be addressed in new builds this week.
Addressed in
Reopening because of