Remove bang = true to permit custom textobject as motion

[dirichy]

Checklist

• Have you read through :h nvim-surround to see if there might be any relevant information there?
  yes
  Is your feature request related to a problem? Please describe.
  If possible, provide a sample buffer/keymap sequence, along with the expected result.
  I have some custom textobject, I want to add surround support for them. but I find that config.selection can only accept vim's motion, not custom motion, because it use vim.cmd({...,bang=true})
  Describe the solution you'd like
  A clear and concise description of what you want to happen.
  remove bang = true
  Additional context
  Add any other context or screenshots about the feature request here.

[kylechui]

Can you provide a minimal init + a test file to reproduce this? I defined a custom omap and this seems to work, e.g.:

vim.keymap.set('o', 'x', "3w", { noremap = true })

-- Before
foo bar baz foo bar baz
-- After `ysxb`
(foo bar baz) foo bar baz

[dirichy]

I mean, in config.get_selection({motion="ax"}), the custom textobject will not work.

vim.keymap.set('o', 'ax', "3w", { noremap = true })

surround.setup({
surrounds={
["x"]={
find=function()
return config.get_selection({motion="ax"})
end,
delete=function()
return config.get_selection({
char="x",pattern="^(%S*)()%s*%S*%s*(%S*)()$"
})
end
}
}
})

I want this:
-- Before
foo bar baz
-- After dsx
bar
but it don't work.

[dirichy]

it' because in buffer.lua about line 118:

    vim.cmd.normal({ args = { "g@" .. motion }, bang = true })

I don't know why we need to set bang = true, this make custion textobject don't work.
Or if we need to ensure g@ is not remapped, may be we can spilt this into two line, only one of which set bang = true.

[kylechui]

You are correct that the purpose of the bang = true is to make sure that g@ is not remapped. I have not come across anyone that has done it before, but I set it there years ago as a precaution. Your use case seems much more reasonable/popular, so I am OK with removing the bang = true from the command.

From some very basic testing, it doesn't seem like it is possible to somehow separate things onto multiple lines. I imagine that it might be possible to resolve this by manually invoking operatorfunc, but I am OK with just removing the bang = true to resolve your issue. Would you like to submit the PR?