Fix outline filtering always selecting last match#50594
Conversation
|
@SomeoneToIgnore sir would love your feedback here, do I require any changes or smthg? Thank you |
SomeoneToIgnore
left a comment
There was a problem hiding this comment.
I need time to do a context switch and focus, that's mainly it — pinging does not help much with this, if not hurts.
My plans to do this next week, maybe on Monday even.
Without understanding the context much: match_update_count usage seems peculiar as it's not clear why this is needed; re-sorting all outline items each time seems odd too — imagine we deal with editor.rs's outlines, and you do that on sorting on the main thread.
SomeoneToIgnore
left a comment
There was a problem hiding this comment.
-
Thank you for the fixes to
block_onand related.
I think we'd better rework the code so that all outline item (after matching the fuzzy match or not) are run ascx.executor().background_spawn(async move {... })task, or at least on the task on the main thread, but asynchronously still, not like what the empty query code path does — this way we'll improve the rendering-related code and stop risking to block it for too long. -
I have been testing in https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide/src/inlay_hints.rs by placing a caret to the beginning and the end of the file, and have noticed that the implementation selects something that's not on the edge for both cases (as I'd expected based on the code changes)
cursor_weight.mov
Is it something expected or should we have more tests and fixes to the comparison code?
|
Thanks @SomeoneToIgnore for the feeback Here are some changes which I did :
|
|
Hey @SomeoneToIgnore sorry it took some time , here are the comparisons : 1] Vs Code : same selects the first one Screencast.from.2026-03-12.18-37-11.webm2] RustRover by Jetbrains : Screencast.from.2026-03-12.19-09-39.webm3] Sublime : Screencast.from.2026-03-12.18-42-14.webm4] Helix : Screencast.from.2026-03-12.18-59-10.webm |
|
Hello @SomeoneToIgnore , did some changes Changes:
Note : I have made 1 change beyond the original discussion, based on manual testing across Helix, VS Code, and Zed with varying caret positions and symbol types (functions, structs, nested items).
|
|
Attaching some visuals example that i tested in Helix , Vscode & fixed in Zed respectively. 1] Search 2] Search 3] Search function 4] Search |
SomeoneToIgnore
left a comment
There was a problem hiding this comment.
Thank you for pushing it forward!
Seems that now we do not select the latest element that aggressively, yet something is a bit odd to me in how we do it that I fail to formulate — this is still quite an increment so let's see how more people find this.
Fixes #29774
When filtering the outline panel, matches with equal fuzzy scores previously defaulted to the last item due to iterator
max_by_keysemantics. This caused the bottommost match (e.g.C::f) to always be pre-selected regardless of cursor position.Changes:
smol::block_on-> asynccx.spawn_in) to avoid blocking during filteringOutline<Anchor>inArcfor cheap cloning into the async taskmatch_update_countto discard results from stale queriesTests :
Adds a regression test:
test_outline_filtered_selection_prefers_cursor_proximity_over_last_tiewhich passesVideo :
Screencast from 2026-03-03 17-01-32.webm
Release Notes:
Fixed the outline filtering always select last match