jiebi/CodeConvo huggingface dataset:
Code change:
) { super(); <del> this.registerSchemas({ defaultSettingsSchema: {}, userSettingsSchema: {}, profileSettingsSchema: {}, machineSettingsSchema: {}, workspaceSettingsSchema: {}, folderSettingsSchema: {}, configDefaultsSchema: {}, }); </del> extensionService.whenInstalledExtensionsRegistered().then(() => { this.registerConfigurationSchemas();

Related discussion:
text: I can't repro deterministically, but I feel like it has to do with loading/reloading the window
Can others subscribed to this issue, please try our latest insiders and let us know if you still see the issue?
/verified
I confirm this is fixed in (tested under Ubuntu 22), and without the need for .
I just upgraded to the regular version and it also seems to be fixed there as expected ^^.
Can U confirm it is now fixed in version 1.80.0 and close the issue ?
The message is still there for me in 1.80.0.
Thanks for confirmation. I will close this as fixed and verified. Please reopen a new issue if you are still seeing it (may be new) with steps to repro.
For me the message showed up in 1.80.0
For me too
Currently experiencing this issue. I can overcome it temporarily following a suggestion elsewhere where I add or remove "": true to my file. I keep adjusting the file to see if there is something in there ausing the issue. Even old, known settings are causing the error to kick in regularly. I put a single setting in there and the error comes up unless it's empty Version: 1.80.0 (user setup) Commit: Date: 2023-07-04T15:06:02.407Z (1 wk ago) Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Currently experiencing the issue on my linux machine. On my Windows machine (with the same configuration file, since it's synchronized) it works fine on stable, but not on insiders. Can confirm that toggling as a workaround works until restart.
Code change:
) { super(); <del> this.registerSchemas({ defaultSettingsSchema: {}, userSettingsSchema: {}, profileSettingsSchema: {}, machineSettingsSchema: {}, workspaceSettingsSchema: {}, folderSettingsSchema: {}, configDefaultsSchema: {}, }); </del> extensionService.whenInstalledExtensionsRegistered().then(() => { this.registerConfigurationSchemas();

Related discussion:
text: Linux version: Version: 1.80.0 Commit: Date: 2023-07-04T13:39:48.236Z (1 wk ago) Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Windows version (stable): Version: 1.80.0 Commit: Date: 2023-07-04T15:06:02.407Z (1 wk ago) Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Windows version (insiders): Version: 1.81.0-insider Commit: Date: 2023-07-13T05:33:32.822Z (2 hrs ago) Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.81.0-insider Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36
Reopening this because it can be still reproduced.
I am getting this error and I can't figure out how to fix it.
Please try our and see if you are still seeing it
Currently seeing this while in a file on GitHub Codespaces, in the following form:
Can you please try insiders and see if you are still seeing this?
I still saw this issue when opening on: Version: 1.80.1 (user setup) Commit: Date: 2023-07-12T17:22:07.651Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
As I mentioned, this was in GitHub Codespaces. I can't change the version of VS Code they serve to the browser.
Code change:
) { super(); <del> this.registerSchemas({ defaultSettingsSchema: {}, userSettingsSchema: {}, profileSettingsSchema: {}, machineSettingsSchema: {}, workspaceSettingsSchema: {}, folderSettingsSchema: {}, configDefaultsSchema: {}, }); </del> extensionService.whenInstalledExtensionsRegistered().then(() => { this.registerConfigurationSchemas();

Related discussion:
text: There should be an action Switch to Insiders... in the settings gear icon in the bottom left corner, do you have that?
uninstalled installed all extensions, including- C# v2.0.328, autopep8 -for python, ctrl+shift+p - selected -format this document with - seleceted C#- All things worked again.
Code change:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

Related discussion:
text: Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified
Code change:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

Related discussion:
text: This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.
Code change:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

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:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

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:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

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:
} this._alertCompletionItem(item); <ins> // clear only now - after all tasks are done Promise.all(tasks).finally(() => { this.model.clear(); cts.dispose(); }); </ins> } getOverwriteInfo(item: CompletionItem, toggleMode: boolean): { overwriteBefore: number, overwriteAfter: number } {

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:
static readonly ID = 'editor.contrib.standaloneColorPickerWidget'; readonly allowEditorOverflow = true; <del> private body: HTMLElement = document.createElement('div'); </del> private readonly _position: Position | undefined = undefined; private readonly _standaloneColorPickerParticipant: StandaloneColorPickerParticipant; <ins> private _body: HTMLElement = document.createElement('div'); </ins> private _colorHover: StandaloneColorPickerHover | null = null; private _selectionSetInEditor: boolean = false;

Related discussion:
text: Depending oh how many editors windows are open and the size of them, sometimes the standalone color picker is partially hidden behind other editor panel. vscode version:1.81.0 x64 !
Code change:
static readonly ID = 'editor.contrib.standaloneColorPickerWidget'; readonly allowEditorOverflow = true; <del> private body: HTMLElement = document.createElement('div'); </del> private readonly _position: Position | undefined = undefined; private readonly _standaloneColorPickerParticipant: StandaloneColorPickerParticipant; <ins> private _body: HTMLElement = document.createElement('div'); </ins> private _colorHover: StandaloneColorPickerHover | null = null; private _selectionSetInEditor: boolean = false;

Related discussion:
text: There is a z-index error: <img width="572" alt="Screenshot 2023-07-25 at 13 56 59" src=""
Code change:
"--vscode-editorWarning-background", "--vscode-editorWarning-border", "--vscode-editorWarning-foreground", <ins> "--vscode-editorWatermark-foreground", </ins> "--vscode-editorWhitespace-foreground", "--vscode-editorWidget-background", "--vscode-editorWidget-border",

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. --I'd like to have a theme setting that would allow me to change the foreground of the text in red next to the shortcuts. I've reached out to the dev tools and wasn't able to track the setting. I searched Google, SO, ChatGPT and I've tested a bunch of foregrounds and nothing works. <img width="1012" alt="Screenshot 2024-01-10 at 16 21 18" src=""
I a new color . It is derived from the
Code change:
if (pick === saveAndCommit) { await Promise.all(documents.map(d => d.save())); <del> await repository.add(documents.map(d => d.uri)); </del> <ins> await repository.add([]); </ins> } else if (pick !== commit) { return false; // do not commit on cancel }

Related discussion:
text: Version: 1.38.0 Commit: Date: 2019-09-03T21:47:00.464Z Electron: 4.2.10 Chrome: 69.0.3497.128 10.11.0 V8: 6.9.427.31-electron.0 OS: Darwin x64 18.0.0 Steps to Reproduce: 1 open multiple tabs and only save some of them. 2 commit and click <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.559 --- <!-- score: 0.518 --- <!-- score: 0.492 --- <!-- score: 0.483 --<!-- potentialduplicatescomment --
Oh yeah. Good catch. Want to submit a fix? Problem is
Hey, I am a new contributor here. I want to give a try on this issue.
Great. Go ahead.
Code change:
const NotebookPreloadContribution = Object.freeze({ type: 'type', entrypoint: 'entrypoint', <ins> localResourceRoots: 'localResourceRoots', </ins> }); interface INotebookPreloadContribution { readonly [NotebookPreloadContribution.type]: string; readonly [NotebookPreloadContribution.entrypoint]: string; <ins> readonly [NotebookPreloadContribution.localResourceRoots]: readonly string[]; </ins> } const notebookProviderContribution: IJSONSchema = {

Related discussion:
text: Originally filed here Problem: Notebook kernel pre-load scripts are now defined statically via the contribution However VS Code throws a 401 error when loading resources from within the Jupyter extension, If however we have a dummy script file (in the Jupyter extension directory) that is defined as a in the VS Code API , then all resources from Jupyter extension directory are loaded I.e. using the above API in some way registers the Juptyer extension directory as a supported for scripts, and using the static contribution does not.
I have a work around in the Jupyter extension right now, i've a dummy placeholder script that does nothing,
Can you share steps to reproduce this with the fix in place? Also, does this happen on normal desktop too, or only sshe Unclear why this is not working as we should add preloads to the local resource roots:
Here are the steps Install Python Install VS Code insiders and latest pre-release versions of Jupyter and Python NOTE: Install the pre-release version of Jupyter extension that is 2 days old Add the following setting into vscode Create a python env and install the following dependencies You can use the command to create a directory with Pytohn in a particular workspace folder (optionally you can use Python extension to do this for you) Run the following code in a notebook pointing to the above venv (i.e. select the above venv as a kernel) You might get prompted to enable CDN download, hit cancel for that The widget will not load, network tab in vscode will display a 401 error Note: This is now working in the latest pre-release version of Jupyter extension
I believe the broken version is be but I'm having trouble reproducing this The output either never renders anything (but there is no network error) or renders as an image: ! ! Any other steps?
Not sure which pre-release to use anymore, as the pre-release has changed since Please use the vsixc from this build (check the artifacts for the vsix) here is the Install Python Add the following setting into vscode (reload VSCode) Create a python env and install the following dependencies You can use the command to create a directory with Pytohn in a particular workspace folder (optionally you can use Python extension to do this for you) Run the following code in a notebook pointing to the above venv (i.e.