Stream: t-compiler/rust-analyzer

Topic: Extending semantic tokens for functions/macro to parens?

woody77 (Aug 21 2020 at 15:32, on Zulip):

In thinking about ways to improve the usability of highlighted code, I was wondering how useful it would be to extend the semantic tokens for functions and macros to cover the parens that follow them (and add the closing paren).

Nested fn calls, arrays, and curly braces from closures are one of the places where I personally find myself getting tripped up, especially as the compilation error may not be near to where the problem is.

(this idea partially inspired by various "rainbow parenthesis" plugins).

matklad (Aug 21 2020 at 17:17, on Zulip):

Hm, this sounds interesting, but I'd say that tracking parantheisi structure shoudl probably be sovled by something other than semhi

matklad (Aug 21 2020 at 17:17, on Zulip):

rainbow parens, breadcrumbs, and parn guides seem to be an overall better fit here

matklad (Aug 21 2020 at 17:18, on Zulip):

(as an aside, we already expose paran info via "go to matching brace" request)

woody77 (Aug 21 2020 at 18:35, on Zulip):

I was thinking something less than the full rainbow, where the parens of a fn were included in its semantic highlight. Which would then allow a pile of closing chars at the end to visually distinguish a bit better:


But there are probably other, better ways to do this.

Paul Faria (Aug 21 2020 at 23:53, on Zulip):

There's already extensions in various editors that support this behavior. For example:

woody77 (Aug 22 2020 at 19:23, on Zulip):

@Paul Faria -> That's a good point, and probably the right way to go about this. I'll look into how VSCode deals with multiple extensions applying formatting.

I think, for me, just hitting these would be a huge win:

It's less the nesting of fns, and more the nesting of the various semantic structures (a closure in an array in a macro...):

let ugly = vec!([34, Foo::Builder({ match bar { Some(thing) => thing.that, None => 5 }})]);
Last update: Jul 24 2021 at 19:45UTC