-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
feat: On type format '(', by adding closing ')' automatically #15532
feat: On type format '(', by adding closing ')' automatically #15532
Conversation
Ah, I was the one who added that assert in, and only realized now that this should be a More context on this assertI originally added this assert since structured snippets add in placeholders & tabstops later on instead of embedding them directly, and I didn't think it was worth it right now to port the on-type formatting to structured snippets as it only uses one tabstop in a fixed location. |
Thank you, works much better with the different assert 🙂 I've pushed the commit here, but feel free to create a separate PR, you have better context and can describe it better. |
☔ The latest upstream changes (presumably #15542) made this pull request unmergeable. Please resolve the merge conflicts. |
Co-authored-by: DropDemBits <[email protected]>
19a5fa9
to
da78617
Compare
Now I wonder, we might as well add |
Well we can do that in separate PR, but I think that should work in all positions there likewise. |
I personally rarely index something nested with this, so was afraid to add it myself. Ideally, I'd add |
I was more thinking of arrays than indexing here, unsure whether its useful though. |
☀️ Test successful - checks-actions |
If I understand right,
()
can surround pretty much the same{}
can, so add another on type formatting pair for convenience: sometimes it's not that pleasant to write parenthesis inSome(2).map(|i| (i, i+1))
cases and I would prefer r-a to do that for me.One note: currently,
rust-analyzer/crates/rust-analyzer/src/handlers/request.rs
Line 357 in b06503b
Should we remove the assertion entirely now, since apparently things work in release despite that check?