-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Don't show expanded items in certain cases #67049
Conversation
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/ItemManager.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/ItemManager.cs
Outdated
Show resolved
Hide resolved
The perf issue is mostly addressed by #67249, but I think there's still value in usability to not show expanded item when filter text is empty |
@dotnet/roslyn-ide @CyrusNajmabadi @sharwell This is now ready for review. Please see the description for the new behavior. Thanks! |
|
||
internal static void LogDelayedImportCompletionIncluded() | ||
=> s_countLogAggregator.IncreaseCount(ActionInfo.SessionWithTypeImportCompletionEnabled); | ||
|
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 telemetry are no longer needed
We only show expanded item if any of the following conditions is true: 1. filter text length >= 2 (it's common to use filter of length 2 for camel case match, e.g. `AB` for `ArrayBuiler`) 2. the completion is triggered after `.` (i.e. in the context of listing members, which usually has much fewer items and more often used for browsing purpose) 3. defaults is not empty (it might suggests an expanded item)
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/CompletionSessionData.cs
Show resolved
Hide resolved
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/CompletionSessionData.cs
Show resolved
Hide resolved
_textView.Options.GlobalOptions.SetOptionValue(s_nonBlockingCompletionEditorOption, !_editorOptionsService.GlobalOptions.GetOption(CompletionViewOptionsStorage.BlockForCompletionItems, service.Language)); | ||
_responsiveCompletionEnabled = _textView.Options.GetOptionValue(DefaultOptions.ResponsiveCompletionOptionId); | ||
var blockForCompletionItem = _editorOptionsService.GlobalOptions.GetOption(CompletionViewOptionsStorage.BlockForCompletionItems, service.Language); | ||
_textView.Options.GlobalOptions.SetOptionValue(s_nonBlockingCompletionEditorOption, !blockForCompletionItem); |
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.
we have another option as well? This now feels like 3 separate options ion this space :) Def confusing. I don't get what each is supposed to control..
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.
I don't have context on this option (CompletionViewOptionsStorage.BlockForCompletionItems), but it seems it was only used for TS and FS to make completion in their files non-blocking.
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.
gotcha... i would love if you could talk to them if we can remove this and they can just use the VS concepts here :) (not blocking (no pun intended) for this pr).
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.
Will do
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/CompletionSource.cs
Show resolved
Hide resolved
AsyncCompletionLogger.LogImportCompletionGetContext(isBlocking: false, delayed: false); | ||
|
||
return CombineCompletionContext(session, nonExpandedContext, expandedContext); | ||
_ = _expandedItemsTaskCancellationSeries.CreateNext(CancellationToken.None); |
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 needs docs as well. i think i get it. you're cancelling any outstanding work since it couldn't result in items that would matter (since you're in exclusive mode). but needs docs to explain and be certain.
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.
question: if we're going to cancel the work anyways... can we not check if things are exclusive first before kicking off the work in the first place?
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.
Yes, your understanding is correct. I will doc this. The reason we kick off the "unimported" task first is because, waiting for the value of exclusivity from regular providers means computation of unimported items won't start until we return those regular items to editor. This combined with the existing behavior of not showing unimported items until they are calculated and only add them during completion list refresh, would mean increased chance users won't see those items for the first few characters they typed.
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.
makes sense. thanks.
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/ItemManager.cs
Outdated
Show resolved
Hide resolved
src/EditorFeatures/Core/IntelliSense/AsyncCompletion/ItemManager.cs
Outdated
Show resolved
Hide resolved
// Don't hide expanded items if all these conditions are met: | ||
// 1. filter text length >= 2 (it's common to use filter of length 2 for camel case match, e.g. `AB` for `ArrayBuiler`) | ||
// 2. the completion is triggered in the context of listing members (it usually has much fewer items and more often used for browsing purpose) | ||
// 3. defaults is not empty (it might suggests an expanded item) |
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.
i don't understand #3. can you expand on that more. Primarily, i don't know what defaults
actually means in the context of completion.
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.
Looking good. But i def have some docs requests, as well as some ideas on where we could either be simpler, or we need docs to explain current complexity.
This change hides expanded items (i.e. unimported items) in certain scenarios even if the option is enabled AND Editor's responsive completion option is also enabled. The goal is to address both usability (showing too many unimported items and cluttered the list, when we don't have enough hint to filter down the list) and perf issues.
Addressing the perf cost in matching and sorting items AB#1749264
Commit-by-commit review is recommended.
AB
forArrayBuiler
, but for 0 (happens quite often since we now trigger completion in argument list by default, where unimported types are rarely needed) or 1 typed char, I don't really see how including thousands of those items would be useful.
(i.e. in the context of listing members, which usually has much fewer items and more often used for browsing purpose)In type context, only show expanded items after at least two characters are typed:
In member context, no change behavior: