-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to a more appropriate model for supporting prefix/suffix text in completoin items. #26764
Switch to a more appropriate model for supporting prefix/suffix text in completoin items. #26764
Conversation
@@ -1 +1,7 @@ | |||
|
|||
*REMOVED*static Microsoft.CodeAnalysis.Completion.CompletionItem.Create(string displayText, string filterText = null, string sortText = null, System.Collections.Immutable.ImmutableDictionary<string, string> properties = null, System.Collections.Immutable.ImmutableArray<string> tags = default(System.Collections.Immutable.ImmutableArray<string>), Microsoft.CodeAnalysis.Completion.CompletionItemRules rules = null) -> Microsoft.CodeAnalysis.Completion.CompletionItem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
intentional. The existing factory method was replaced with one with non-optional params (for binary compat). A new factory method was added that allows for the new pieces of data to be passed along. This is our pattern for adding new data to types without breaking binary compat.
/// Pattern-matching of user input will not be performed against this, but only against <see | ||
/// cref="DisplayText"/>. | ||
/// </summary> | ||
public string DisplayTextPrefix { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are new public APIs that will have to be approved.
26b8184
to
63ae355
Compare
…in completion items.
1a2783a
to
14aaf8b
Compare
@dotnet/roslyn-ide for review. |
Note: our test infrastructure here is pretty bad (likely due to all the completoin rewrites, without really investing in moving the test harness forward as well). Fortunately, we do have a ton of coverage. So there is good confidence this is all working properly. |
@@ -413,7 +420,7 @@ protected virtual void SetWorkspaceOptions(TestWorkspace workspace) | |||
await VerifyProviderCommitCheckResultsAsync(document2, position, itemToCommit, expectedCodeAfterCommit, commitChar, textTypedSoFar); | |||
} | |||
} | |||
|
|||
private async Task VerifyProviderCommitCheckResultsAsync( | |||
Document document, int position, string itemToCommit, string expectedCodeAfterCommit, char? commitCharOpt, string textTypedSoFar) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this entire test method is effectively bogus. It's "attempting" to validate that post commit, the file will look like what is expected. However, it's not going through the actual controller commit codepath. Instead, it's just simulating what it thinks would happen. This entire test method should be removed, and all tests that depend on it should become CompletoinCommandHandler tests.
@ivanbasov Can this be looked at? It's been a month completely stalled :-/ |
@dpoeschl @dotnet/roslyn-ide @sharwell @ivanbasov Can this be looked at? It's been a month completely stalled :-/ |
@CyrusNajmabadi , would like to take this as a follow-up after #25770 |
@jinujoseph Honestly, i think this PR shoudl go in now (once reviewed). Based on the approach taken in the async-completion branch, i actually think it's more critical that we have sufficient designs/testing here to ensure that the async-completion work is actually suitable and capable of doing all the things we need, without changing behavior or otherwise regressing anything. This PR puts in a proper design for how we handle things like "intellicode stars" while also removing technical debt and bugs incurred with the original approach here. I think it would be sensible to get this in sooner rather than later. Thanks! |
@@ -498,7 +498,7 @@ private bool IsBetterDeletionMatch(FilterResult result1, FilterResult result2) | |||
|
|||
private static int GetRecentItemIndex(ImmutableArray<string> recentItems, CompletionItem item) | |||
{ | |||
var index = recentItems.IndexOf(CompletionHelper.GetDisplayTextForMatching(item)); | |||
var index = recentItems.IndexOf(item.DisplayText); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: this is super weird. effectively, this means the intellicode 'star' prefix now becomes part of the MRU... That doesn't seem to make any sense whatsoever.
@dpoeschl @ivanbasov Please take a look and let me know your thoughts here. If you want, i can help merge this into your feature branch. |
Function AssertSelectedCompletionItem( | ||
Optional displayText As String = Nothing, | ||
Optional description As String = Nothing, | ||
Optional isSoftSelected As Boolean? = Nothing, | ||
Optional isHardSelected As Boolean? = Nothing, | ||
Optional displayTextSuffix As String = Nothing, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional displayTextSuffix As String = Nothing, [](start = 31, length = 47)
put it closer in order to displayText?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that woudl require updating a huge amount of tests taht currently do not pass along displayTextSuffix, but do pass along display/description. i'd prefer to not do that :)
@@ -104,6 +104,7 @@ protected CompletionItem CreateSuggestionModeItem(string displayText, string des | |||
{ | |||
return CommonCompletionItem.Create( | |||
displayText: displayText ?? string.Empty, | |||
displayTextSuffix: "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"" [](start = 35, length = 2)
nit: string.Empty
string sortText, | ||
ImmutableDictionary<string, string> properties, | ||
ImmutableArray<string> tags, | ||
CompletionItemRules rules) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we care about consistency of order of parameters for the CompletionItem and CommonCompleitonItem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now they're completely inconsistent. CompletionItem needs to work this way because it's a public API. CommonCompletionItem is basically a grab bag of whatever we needed in whatever order we wanted over time. We could reorder it if we wanted, but it didn't seem necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🕐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
17c40d2
to
9e26ef5
Compare
@ivanbasov Ready to merge. Thanks! |
Thank you very much, @CyrusNajmabadi, for you help! |
Thanks @ivanbasov ! |
Fixes #26686
Tagging @dpoeschl .
Note: one nice thing about this model is that it actually cleans up a bunch of stuff in our code. For example, all the places we used to have to jam on special suffixes (like
<>
) which we then had to special case later.