Ensure the initial symbol a user searches for is top of hte find-refs list #43472
Conversation
CyrusNajmabadi
requested review from
devopsjesus,
jasonmalinowski,
dpoeschl and
ryzngard
CyrusNajmabadi
force-pushed
the
findRefsCollapsing
branch
from
f90d436 to
5a215f3
Compare
| @@ -28,9 +28,6 @@ internal abstract partial class AbstractFindUsagesService | |||
| if (moniker == null) | |||
| return; | |||
|
|
|||
| // Let the find-refs window know we have outstanding work | |||
| await using var _ = await context.ProgressTracker.AddSingleItemAsync().ConfigureAwait(false); | |||
There was a problem hiding this comment.
intentional removal. progress tracking doesn't work well for richnav as we don't really know how many items it will need to search. so trying to evne add progress items for it just ends up interfering with the good progress bar we have for the normal find-refs for user code in their solution.
There was a problem hiding this comment.
Ah, so we did all that refactoring work to then not use it? 😄
There was a problem hiding this comment.
it's used elsewhere :) just here it's not particularly good and def degrades the experience. i.e. if you do have code-index, we just jump to the 50% point immediately because it says "i have one piece of work", and then finishes it. The other part of find refs has has added one piece of owrk that is not done, causing us to be at 1-of-2 done.
This is unlike normal find refs, which can add a bunch of known work it needs to do (like looking at all files with bloom filter matches) which gives far more fine-grained progress.
| // Only grab the first 500 results. This keeps server load lower and is acceptable for //build demo purposes. | ||
| const int PageCount = 5; |
There was a problem hiding this comment.
Did this mean to come in this PR or something else?
There was a problem hiding this comment.
yes. i pulled this in from my main richnav PR (which i'm still trying to get in).
ghost
merged commit 
Also, collapse all definitions we cascade to by default. Looks like this: