jiebi/CodeConvo huggingface dataset:
Code change:
import { SnippetController2 } from 'vs/editor/contrib/snippet/snippetController2'; import { IMenuService, IMenu } from 'vs/platform/actions/common/actions'; import { createTextModel } from 'vs/editor/test/common/editorTestUtils'; <ins> import { Range } from 'vs/editor/common/core/range'; import { timeout } from 'vs/base/common/async'; </ins> suite('SuggestController', function () {

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 { SnippetController2 } from 'vs/editor/contrib/snippet/snippetController2'; import { IMenuService, IMenu } from 'vs/platform/actions/common/actions'; import { createTextModel } from 'vs/editor/test/common/editorTestUtils'; <ins> import { Range } from 'vs/editor/common/core/range'; import { timeout } from 'vs/base/common/async'; </ins> suite('SuggestController', function () {

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 { SnippetController2 } from 'vs/editor/contrib/snippet/snippetController2'; import { IMenuService, IMenu } from 'vs/platform/actions/common/actions'; import { createTextModel } from 'vs/editor/test/common/editorTestUtils'; <ins> import { Range } from 'vs/editor/common/core/range'; import { timeout } from 'vs/base/common/async'; </ins> suite('SuggestController', function () {

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 { SnippetController2 } from 'vs/editor/contrib/snippet/snippetController2'; import { IMenuService, IMenu } from 'vs/platform/actions/common/actions'; import { createTextModel } from 'vs/editor/test/common/editorTestUtils'; <ins> import { Range } from 'vs/editor/common/core/range'; import { timeout } from 'vs/base/common/async'; </ins> suite('SuggestController', function () {

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:
// enable signing of commits if configurated opts.signCommit = enableCommitSigning; <ins> if (config.get<boolean>('alwaysSignOff')) { opts.signoff = true; } </ins> if ( // no changes (noStagedChanges && noUnstagedChanges)

Related discussion:
text: For some projects, every commit has to have the signed off by tag. It would be very helpful if there was a workspace level setting that enabled signed off by flag when committing.
Verified !
Code change:
} export interface MainThreadProfileContentHandlersShape { <del> $registerProfileContentHandler(id: string, name: string, extensionId: string): Promise<void>; </del> <ins> $registerProfileContentHandler(id: string, name: string, description: string | undefined, extensionId: string): Promise<void>; </ins> $unregisterProfileContentHandler(id: string): Promise<void>; }

Related discussion:
text: Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.
Code change:
}, "dependencies": { "@vscode/extension-telemetry": "0.5.1", <del> "vscode-languageclient": "^8.0.1", </del> <ins> "vscode-languageclient": "^8.0.2-next.4", </ins> "vscode-nls": "^5.0.1", "vscode-uri": "^3.0.3" },

Related discussion:
text: Version: 1.68.0-insider Commit: Date: 2022-06-02T05:17:01.962Z open the Settings JSON editor add some unnecessary commas no problems reported in the problems view. open the JSON Language Server log. Observe that there are no diagnostic requests. Other requests are sent and completed, so the language server is running.
Maybe unrelated: I was expecting "trailing comma" warnings in (we recently changed the schema to not accept them), but they only started showing after I flushed the schema cache (using the UI command) and reloaded the window (I can't completely rule out that a window reload alone would have helped).
I checked that with the fix the trailing commas are reported
Code change:
viewState: ISettingsEditorViewState, settingsOrderByTocIndex: Map<string, number> | null, isWorkspaceTrusted: boolean, <del> @IWorkbenchConfigurationService private readonly configurationService: IWorkbenchConfigurationService, </del> <ins> @IWorkbenchConfigurationService configurationService: IWorkbenchConfigurationService, </ins> @IWorkbenchEnvironmentService private readonly environmentService: IWorkbenchEnvironmentService, @ILanguageService languageService: ILanguageService, @IUserDataProfileService userDataProfileService: IUserDataProfileService,

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 proposal affects Settings editor (Settings UI) users and extension authors. The search in the Settings editor currently shows results sorted by the table of contents so that commonly used settings can show up at the top, and so search results can be grouped by the entries in the table of contents. The change to sort the settings by table of contents was made as part of and However, the Settings editor performs two searches per query: the first search finds settings based on keyword matching, and the second search attempts to find relevant settings using similarity search algorithms. As a result, the second search is prone to finding less relevant settings, especially when the user had a specific keyword in mind. Because the Settings editor currently orders settings by the table of contents, the less relevant results from the second search sometimes end up showing above the keyword match results because they appear first in the table of contents. As an example, if I search "title bar style" in the Settings editor, actually shows up fifth due to table of contents sorting: ! This issue proposes reverting the settings search so that the keyword matches always appear at the top of the search results again. As part of this proposal, and would regress and become out of scope. In other words, ordering the search results so that keyword matches always appear first would break grouping the search results by the table of contents entries, but would make it so that users hopefully don't have to scroll down as much to find what they were looking for. Implementing this proposal would also break sorting extension search results by the settings order numbers given by the extension author in their extension's file. I noticed that the issue of having to scroll down to find a keyword match is made worse when the Settings editor is "small", such as when I restore/shrink the VS Code window. Screenreader users might also have to tab down more search results to get to the one they want. Feel free to upvote the proposal if you'd like to see it implemented, or downvote it if you'd like the settings search results ordering to remain the way it currently is. You're also welcome to comment on this issue with alternative suggestions for how the search results should be shown within the Settings editor.
Code change:
viewState: ISettingsEditorViewState, settingsOrderByTocIndex: Map<string, number> | null, isWorkspaceTrusted: boolean, <del> @IWorkbenchConfigurationService private readonly configurationService: IWorkbenchConfigurationService, </del> <ins> @IWorkbenchConfigurationService configurationService: IWorkbenchConfigurationService, </ins> @IWorkbenchEnvironmentService private readonly environmentService: IWorkbenchEnvironmentService, @ILanguageService languageService: ILanguageService, @IUserDataProfileService userDataProfileService: IUserDataProfileService,

Related discussion:
text: Pinging authors of the issues above along with those who I have seen express interest in reverting the behaviour:
Another idea I have rather than doing a full revert is to use table of contents order as a last resort sorting key for the keyword matches. Therefore, keyword matches in the title could come before keyword matches in the description, and the settings that all have a description-only keyword match could be sorted amongst themselves by table of contents order. With this concept, some extension settings could preserve their order, but an extension setting found by keyword matching would still always come before an extension setting found by a similarity algorithm.
To revert the search results in the Settings editor to order by keyword matches first in the Visual Studio Code extension, you can follow these steps Open the Settings editor: You can do this by pressing the Ctrl+, (Windows, Linux) or Cmd+, (macOS) keyboard shortcut, or by clicking on the gear icon in the Activity Bar and selecting "Settings" from the dropdown menu. Search for the "workbench.settings.settingsSearchTocBehavior" setting: In the search bar at the top of the Settings editor, type "workbench.settings.settingsSearchTocBehavior". Change the value of the setting to "hide": Click on the dropdown menu next to the setting and select "hide". This will disable the table of contents ordering and prioritize keyword matches. Restart Visual Studio Code: To apply the changes, you need to restart Visual Studio Code. Once you restart, the search results in the Settings editor will be ordered by keyword matches first.
that behaviour was implemented as part of , and yes, it is a workaround in a sense. This proposal is on ordering results by keyword matches first even when the table of contents is shown.
Try doing this way In the file, add the following property to the contributes section: { "name": "revert-settings-search-to-keyword-matches-first", "version": "1.0.0", "description": "Reverts settings search in the Settings editor to order results by keyword matches first.
Code change:
viewState: ISettingsEditorViewState, settingsOrderByTocIndex: Map<string, number> | null, isWorkspaceTrusted: boolean, <del> @IWorkbenchConfigurationService private readonly configurationService: IWorkbenchConfigurationService, </del> <ins> @IWorkbenchConfigurationService configurationService: IWorkbenchConfigurationService, </ins> @IWorkbenchEnvironmentService private readonly environmentService: IWorkbenchEnvironmentService, @ILanguageService languageService: ILanguageService, @IUserDataProfileService userDataProfileService: IUserDataProfileService,

Related discussion:
text: ", "publisher": "your-name", "categories": ["Settings"], "activationEvents": ["onStartup"], "contributes": { "configuration": { "properties": { "search.settings.sortByKeywordMatchesFirst": { "type": "boolean", "default": true } } } }, "main": "" } the extension's main script file, add the following code: const vscode = require('vscode'); vscode.extensions.onDidChangeConfiguration(() ={ const sortByKeywordMatchesFirst = vscode.workspace.getConfiguration('search').get('settings.sortByKeywordMatchesFirst'); // Update the Settings editor's search sorting algorithm here. });
Since I am coming from , it would be important to me that the order determined by the extension is retained when only " is called (as you also suggested in ). This then serves as a filter for the items in the base order. If you then place a keyword behind it, you can search "smartly" again.
Verification notes: for title bar style should show the setting first no matter what value is set to. for should show the CSS category first, followed by the LESS category, and lastly by the SCSS category.
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: 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:
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: 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.