|
|
|
|
|
by narnarpapadaddy
502 days ago
|
|
I think I understand the use case for a smart surround plugin like this; I watched the demo video and saw and lot of picking-and-pulling text. What I don’t understand is the development workflow that includes so much text manipulation. If you’re writing new code, there’s nothing to manipulate. If you’re refactoring existing code, wouldn’t you want the support typical AST-based refactoring tools provide? Where’s the sweet spot where shuffling strings around makes sense? That’s not sarcasm. I’m genuinely asking. |
|
1. LSPs differ per-language, and so I'm never sure whether I'll get lucky today or not. It's more reliable for small changes to talk about them in terms of the text.
2. LSPs are also quite slow. For example in Zed I can do a quick local rename with `ga` to multi-cursor onto matching words and then `s new_name` to change it. (For larger or cross-file renames I still use the LSP).
3. I err as a human continually, for example in Rust a string is `"a"` and a char is `'a'`. It's easy for my javascript addled brain to use the wrong quotes. I don't know of any LSP operation that does "convert string literal into char literal" (or vice versa), but in vim, it's easy.
We are slowly pulling in support for various vim plugins; but the tail is long and I am not likely to build a vim-compatible Lua (or VimScript :D) API any time soon.
For example, most of vim-surround already works so you could get the most used parts of mini.surround to work with just a few keybindings `"s a":["vim::PushOperator", { "AddSurrounds": {} }]`, but rebuilding every plugin is a labor of love :D.