`dsb` / `ysiw"` actions etc. do not work when run inside a different buffer

[smjonas]

Checklist

• [X] Have you updated the plugin to the latest version on main branch?
• [X] Have you checked the Breaking Changes issue?
• [X] Have you read through :h nvim-surround to see if there might be any relevant information there?

Describe the bug Ok, this might be kind of an unusual bug but please hear me out. When running :norm dsb in the current buffer, everything works as expected. However, run it in a different buffer and it won't work anymore. I came across this bug while working on my plugin command-preview.nvim.

To Reproduce

Paste this Lua code somewhere in your config and run it:

-- Create a scratch buffer with a single line
local scratch_buf = vim.api.nvim_create_buf(true, true)
vim.api.nvim_buf_set_lines(scratch_buf, 0, -1, false, { "Some (Line)" })

-- Run "norm dsb" in the scratch buffer using bufdo
vim.cmd(scratch_buf .. "bufdo norm dsb")

-- Retrieve the lines in the scratch buffer
local updated_lines = vim.api.nvim_buf_get_lines(scratch_buf, 0, -1, false) or {}
-- Prints { "Some (Line)" }; expected: { "Some Line" }
vim.pretty_print(updated_lines)

Expected behavior Deletion of brackets should work inside the scratch buffer, { "Some Line" } should be printed.

Additional context To confirm that my reproduction code makes sense, simply replace args = { "norm dsb" } with args = { "norm Axxx" }. This will output { "Some (Line)xxx" }, as expected.

[kylechui]

Unsure if I'm misreading this, but I created a new scratch buffer (just enter nvim from the terminal), and I populated it with the contents

test "string"

Then running :bufdo norm ds" deletes the quotes. I'm not sure if this is the same thing, nor if the new buffer is considered a "scratch" buffer, but it does say [No Name] for the file name.

[smjonas]

I think I found the issue: The order in which the relevant events happen is as follows:

• scratch buffer is created
• bufdo norm dsb is run
• lines are retrieved from the buffer and printed
• BufEnter autocommand in nvim-surround is triggered which sets up the buffer mappings

So it seems I need to wait until this autocommand has been triggered. I'll report back if I found the final solution, maybe I'll have to use vim.schedule or something :)

[smjonas]

Could the mappings simply be defined globally? This would solve my issue (I have tested it :tada:). Currently, I don't see why the mappings should be buffer-local anyway:

• When using Telescope, a new mapping will be created for each file that is previewed which seems wasteful and could potentially impact performance.
• Currently, there is no way to disable nvim-surround for specific filetypes so this makes no functional difference (even if there will be such a feature in the future, there could be simply be a check for the current filetype before executing the mapping).
• As a bonus, this would simplify the code quite a bit (can get rid of buffer-local options such as nvim_surround_buffer_opts and config.get_opts() won't be necessary anymore).

What do you think?

[kylechui]

The point of buffer-local maps is to let the user have different mappings per buffer, e.g. ysiwf could have different meanings per language, as different function syntaxes are used. I think your concern about performance/runtime order is valid though, and I have a fix in mind for that (perhaps coming later today).

[kylechui]

If you want to get more familiar with the codebase, the TL;DR is that as of right now buffer-local maps are getting created/called for every buffer, via that autocommand. Furthermore, config.get_opts() is only referring to the buffer-local opts (which always exist, as they are created on every BufEnter event). My idea right now is just to remove the autocommand, and then have config.get_opts() "fallback" on config.user_opts whenever the buffer-local variable doesn't exist. Hopefully that clears some things up.

Edit: I guess in a sense they already are defined globally via config.user_opts, I just didn't think to use it that way after creating the buffer-local options haha

[kylechui]

Since I'm feeling quite stuck on #58, I'll write this up real quick on branch lazy-load-options.

Edit: I didn't really add/change much since I already had a layer of abstraction via config.get_opts(), so hopefully it "just works" for your needs? Let me know if it fixes your issue!

[smjonas]

Yes, it is working now, thank you very much! :sparkles: So this can be closed when the lazy-load-options branch has been merged.

[kylechui]

Merged as of #92.