Should custom operator-mode mappings be set by nvim-surround?

[kylechui]

In the code, certain single-character aliases are added to make it easier for people to manipulate surroundings, e.g. r for ] and a for >. This allows for more ergonomic/comfortable input strings, e.g. csar instead of cs>]. However, this does not extend to insert surrounds, which are unprocessed by nvim-surround before getting sent to Neovim itself. Thus commands like ysarb are not valid, as ar is not a builtin text-object. This can be circumvented by having nvim-surround define these objects:

vim.keymap.set("o", "ar", "a]", { buffer = true })
vim.keymap.set("o", "ir", "i]", { buffer = true })
vim.keymap.set("o", "aa", "a>", { buffer = true })
vim.keymap.set("o", "ia", "i>", { buffer = true })

[andrewferrier]

Personally, I would say no. I was never a fan of q as an alias for " and ' anyway (in my mind, you can see what you want to delete on the screen, so just press it! - but I know others feel differently, and you are copying vim-surround's behaviour here, which is a good reason). But irrespective, I think these pollute an already-precious limited number of characters available for keymappings, so I would suggest setting them up automatically might be a mistake. I would suggest this is something you explain in the help and/or the README, and let the user decide for themselves.

[andrewferrier]

At the very least, if you are keen to do it, I suggest you should provide an option to disable setting them up. It would be annoying if the user had another ar or aa text object and you overwrote it.

[NoahTheDuke]

I think defining them in the app is good but wrapping them in a setting is better. I prefer plugins that make the hard decision of "what keymap do I set this as?" for me, but this is more esoteric than the others, so adding a setting in the setup method feels right.

require("nvim-surround").setup({
  mnemonic_keymaps = true,
  delimiters = {

I personally don't use the mnemonic keymaps yet so maybe my vote should count less lol.

[kylechui]

I was thinking of doing this if anything at all, as well as notifying the user if there were existing omaps that were about to be overwritten, but I think @andrewferrier has a good point in trying to limit polluting keymaps. My main concern was the "somewhat complex" nature of the aliasing then, since not having these omaps set means I have to say "they stand in for the character almost everywhere", since I've already enabled them in processing for changes/deletions, but can't for insertions.

[andrewferrier]

@kylechui what I have seen older Vim plugins do is gracefully check if keymaps already exist, and not overwrite them if so. That doesn't always work though, because then you become very dependent on the order in which plugins load (not always predictable). So I wouldn't do that. I would suggest if you do want to set them in your plugin, just do it the normal way (@NoahTheDuke has a good point that sometimes it is good when plugins make the choice for you, as it sets a good convention) but provide an easy way to turn the behavior off. Personally I would suggest a simple boolean to cover all of them is OK, since more advanced users won't have a problem creating their own if they want to customize (you could even point them to where in your plugin's code you do to give a headstart). And maybe spend just a little time researching other plugins to minimize the chance of conflicts...

[andrewferrier]

Notifying might be helpful but that's more advanced behaviour - I can't recall any other plugin where I've seen it do that actually.

[kylechui]

Very good point about plugin load order being indeterminate; I think I'll err on the side of caution here and just mention it in the help documentation, since the mappings themselves aren't that complicated anyways. As for notifying about conflicting keymaps, I think folke's which-key does this? But I haven't used that too much so I can't say for sure