Use vim-surround without changing cursor position

[iago-lito]

Hi,

First of all, thank you for this amazing plugin and for supporting it! I would love vim-surround supporting a feature that I can't find in the doc : is it possible

• adding a surround

• changing a surround

• deleting a surround

  without :

• in normal mode, changing the cursor position?

• in visual mode, loosing the selection?

  I guess this would just be some 2 or 3 constants to define for the user:

• one would allow saving the cursor position while using surround in nmode

• one would allow saving the current selected text while using surround in vmode

  • if this one is set, one more would allow choosing wether or not including the new surroundings to the current selection

  I also guess this wouldn't be too much to implement as it does not alter the core behavior of vim-surround. But if ever it was, would you know an easy workaround? I can easily use custom mappings, using marks to get back to my position or using gv to get my previous selection, for example with:

  :vmap s" S"gvhol :noremap s" maysiw"`a

  , but it looks stupid trying to map every possible surrounding command to get this behavior.

  This is it, thank you and keep up with the good work! :)

Iago-lito

[tommcdo]

Duplicate of #148?

[iago-lito]

Wops! Confirmed. I agree this wouldn't be consistent with other Vim operators, even though making it optionnal wouldn't change the default behavior. Sorry for the duplicate.

To make use of #160 then, what workaround could I use to get this behaviour, appart from scrupulously re-mapping every possible surround/delete/change surrounds operations?

[liloman]

Related to mine also: #150

[unphased]

@iago-lito did you ever implement what you asked for? I have the same ask after 10+ years heavily using vim (now nvim).

I totally get the rationale of consistency as explained in #148, but the truth is that as humans we want the cursor to go to a place where we are more likely to focus on next.

To argue that gUi" (upper case within double quotes) is a similar operation to csBb (change surrounding brackets to parens) is kind of absurd because it is not a similar operation, the former changes all the chars so it is natural to leave the cursor at the front of the changed chars.

I suppose the argument is that the latter changes the two surrounding bracket chars into paren chars, so we put the cursor on the first char that changed, the consistency that exists is that vim consistently places the cursor on the location of the change. Never mind that there is a second corresponding character that changes in this case.

Well... that could be a sensible behavior, from a computer perspective, but it is more or less hostile UX for the user, because the very change itself is explicitly spelled out in the command which we already entered, so to assume I want to then make further modifications to the starting paren or something nearby to it is not a good assumption to make.

Therefore, as @iago-lito stated in the OP I would definitely say since all surround based modification operations are fully specified commands we should not assume the user made a mistake in submitting the command and instead restore the cursor to where it was.

I'll even grant you sometimes it is useful to get the cursor where it goes because i will use other plugins to manipulate the surrounder. For example I use tree sitter node action to toggle stuff between multiline and one line which happens a lot with blocks within braces, and this is best done with the cursor on top of a brace.

But the big source of pain is when you are doing some simple thing like change the type of a surrounding quote which happens a lot in almost all languages when the content of a string gains a character that requires you to change the quote type, and it yanks my cursor away. Probably i would want to just change the behavior of the quote surround ones only to save and restore cursor.

[iago-lito]

@unphased I did not. I guess I just grew used to it, although I must admit that I still find it rather annoying ^ ^"

[unphased]

great, thanks for getting back to me. this is a firmly low priority niggle with (n)vim for me at the moment. but one of these days i'm going to definitely try a recursive map for various quotes to implement what i described, and see if i like it better.