Skip to content
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

Wrap operation #99

Open
Kixunil opened this issue Mar 9, 2021 · 2 comments
Open

Wrap operation #99

Kixunil opened this issue Mar 9, 2021 · 2 comments

Comments

@Kixunil
Copy link
Contributor

Kixunil commented Mar 9, 2021

One editing operation that often comes up is wrapping a subtree in another node.
An example that happened to me recently in Rust if changing Type to Option<Type> in several places.
It'd be really great if we could have such wrapping operation built-in, as that'd help with these. However there's an interesting case - what if I wanted to wrap into Result? Which type parameter should be picked?

I envision something like this:

wo - wrap as Option<T>, no indication is needed as it's obviously one
w1r - wrap as Result<T, _>
w2r - wrap as Result<_, T>
w1o - same as wo
wr - error because of ambiguity (but equivalent to w1r would also make sense as this operation is more common in case of Result)

Dot command should work with this too, also multi-cursor operations. (Select all occurrences of Type within a subtree and wrap them.)

@kneasle
Copy link
Owner

kneasle commented Mar 9, 2021

Yep I'd like to see this too 😃. I was thinking that you could have w for 'wrap' and W for 'wrap individually', so you could e.g. turn {<true>, <false>} into {<[true]>, <[false]>} (W) or {<[true, false]>} (w). Slurp and barf are also cool and useful.

I'm not sure sure how I feel about having shortcuts for Option and Result, on the basis that you might want to wrap with any type - much easier I reckon to perform the wrap and then put the user into 'stringly-edit' mode to let them enter the name themselves. If the LSP/intellisense is good enough, then you should be able to type o<tab> to get Option, and r<tab> to get Result. Not ideal in terms of key inputs, but I don't think the gain of having special shortcuts for types in the prelude is worth the extra memory load...

@Kixunil
Copy link
Contributor Author

Kixunil commented Mar 10, 2021

Yeah, I didn't mean specific shortcuts, they were just examples. But having an option to have a binding for such shortcuts would be cool. I'd definitely try these specific to see how it improves experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants