Closed Veykril closed 2 months ago
@rustbot claim
For the return
kw, should we navigate to the def (i.e., the function name), the arrow->
or the fn
keyword of the function?
fn
keyword I'd say, for closures the opening bar and for async blocks the async keyword
I've encountered some difficulties handling macros:
Currently, for functions, I can correctly handle three scenarios (see GIF):
and mixture of them.
These can be handled using NavigationTarget::from_named
(orig_range_with_focus
). However, how should I handle closures? Since closures don't have names, can they be mapped through SpanMap?
They can be mapped just fine, it's just that we have no API in NavigationTarget
for anything without names.
Currently, placing the cursor over return
(in async
block) highlights the corresponding async
, while placing it over async
just highlights all await
. It's a bit inconsistent.
Should we implement a similar approach for goto-definition and goto-references? 🤔 Or changed it to be:
return
corresponds to the {
of the async
blockasync
kw corresponds to await
kwI think for async blocks we might just wanna highlight await and return together. {
isnt really intuitive for this
We currently highlight relevant control flow structures when the cursor is on a relevant keyword, an example being highlighting all
await
s when on an async fn'sasync
keyword, or all loop control flow keywords when it is on the loops keyword. We can do more things here I'd say.Go to def/decl
onreturn
could go the relevant closure/fn,continue
andbreak
to the corresponding loop (or block for labeled blocks), go to references could do the same as the highlighting