Release v2.0.0

[kylechui]

Breaking Changes

TODO: In the actual release notes, just link to #77

Some user configuration variables have been renamed to better reflect their actual purpose:

• highlight_motion → highlight
• NvimSurroundHighlightTextObject → NvimSurroundHighlight
• The textobject key for require("nvim-surround.config").get_selection() has been replaced by the motion key. This allows for better compatibility with targets.vim and similar plugins that define their own text-objects. All existing textobject keys just need to be pre-pended with a to represent the correct motion, e.g.

-- Old configuration
require("nvim-surround.config").get_selection({
    textobject = ")",
})
-- New configuration
require("nvim-surround.config").get_selection({
    motion = "a)",
})

New Features

• Adds first-class Tree-sitter support for finding parent selections; see :h nvim-surround.config.get_selection()
  • This allows for dsf to better handle edge cases like smiley_face(":)")
• Filetype-specific surrounds (that utilize Tree-sitter) can be set by default
• nvim-surround indentation can be disabled by setting the new key indent_lines = false; see :h nvim-surround.config.indent_lines

Bug Fixes

• Configuration got much simpler, see How to configure after the latest changes? #128
  • When modifying defaults, only the modified keys need to be provided, instead of all keys
  • The change.target key (and subsequently the change key) is now optional, and will default to delete key instead. This is analogous to change.replacement and add
• HTML/JSX-style tag types can include punctuation and other non-whitespace characters, see Allow updating tags with punctuation #127
• Multi-byte characters are now correctly surrounded, see Multibyte (Unicode/CJK) characters are incorrectly surrounded #131

Future Goals

• Toggle surrounds via ts prefix, see Toggle quotes (ts) #98
• [Tentative] Delete "around" and "inside" surrounds, see Use surrounds as textobjects (like vim-sandwich) #135 (if you want this feature, show your support here!)
  • Perhaps using das/dis keymaps, still in the works

[smjonas]

Looks like there should be a nil-check here in case there is no function for the given filetype :)

[kylechui]

@smjonas I actually forgot I accounted for this, but there will always exist a function for the given filetype, since the autocommand uses the M.filetype_configurations table to even choose which files to run on. So this shouldn't be an issue as far as I can tell :) Thanks for checking though!

[smjonas]

Ah, you're right, I missed that :D

[latipun7]

nvim-surround/lua/nvim-surround/init.lua

Lines 10 to 13 in 28aa65e

	---@field add function
	---@field find function
	---@field delete function
	---@field change { target: function, replacement: function? }

Those lines causing LSP problems as shown below.

Please add string type to find, delete, and target fields and add string[] to the add field since documentation said that those fileds can accept string type while add field can take the list of string.

[kylechui]

Hmm I didn't realize that LSP would actually tell you about that; the reason why I initially omitted them is because when nvim-surround stores everything in a buffer-local variable, it actually "translates" all user configuration to a standardized, internal format. For example add = { "(", ")" } gets converted to add = function() return { { "(" }, { ")" } } end. For the time being this will work just fine, but I wonder if I should create two sets of type annotations, one for user-facing configuration and one for the internal workings. Thanks for the comment @latipun7

[smjonas]

One suggestion for this release:
For custom surrounds, it is often the case that delete and change.target need to be set to the same pattern. I would even say that this is the case for the majority of surrounds. Examples: simple character surrounds such as surrounding with ** or a function call such as pretty_print in Lua.

Would you consider falling back to the delete pattern if change.target is nil? This would reduce code duplication for the user and simplifies the API. It would still be possible to disable change entirely if set to an empty function, right?

Example:
Old:

    p = {
      add = { "vim.pretty_print(", ")" },
      find = "vim%.pretty_print%b()",
      delete = "^(vim%.pretty_print%()().-(%))()$",
      change = {
        target = "^(vim%.pretty_print%()().-(%))()$",
      },
    },

New:

    p = {
      add = { "vim.pretty_print(", ")" },
      find = "vim%.pretty_print%b()",
      delete = "^(vim%.pretty_print%()().-(%))()$",
    },

csp will still work as before.

Let me know what you think!

[kylechui]

@smjonas Very good point. I suppose change is only different from a literal add/delete pair if it's more complex (e.g. function call, HTML tag), and isn't actually necessary most of the time. I'll add this in at some point; still working on user interface for default filetype-specific surrounds. Design is hard 😅

[kylechui]

@smjonas Added in the latest commit, thanks for the great suggestion!

[smjonas]

Awesome, thank you for implementing that so fast!

[kylechui]

If you actually look at the commit it was honestly a really quick fix, just added like 3-4 lines :)

[kylechui]

Oh wait @smjonas an interesting (new) issue cropped up as a result of defaulting to delete; in the case that a buffer-local setup does not define change.target, should it default to that surround's delete key, or the global surround's change.target key? In particular, if the f surround for Lua files is set by

require("nvim-surround").buffer_setup({
    surrounds = {
        ["f"] = {
            find = function()
                return config.get_selection({ node = "function_call" })
            end,
            delete = "^([^=%s]+%()().-(%))()$",
        },
    },
})

then csf will include the closing parenthesis, since it is falling back on the delete key. I'm not sure if changing it to look globally first will cause any other unforeseen issues though :/

[smjonas]

I would suggest to only fallback to the local surround's delete key. This way, users can immediately tell what will happen without having to look at the global configuration first. My suggestion was mainly intended to reduce duplicate code within a single surround.

[kylechui]

Hmm... this behavior might actually be unrelated; will do some more investigating.

Edit: It was unrelated. Oops!

[kylechui]

@smjonas I've decided on falling back on globals first, since I don't think it makes sense that tweaking delete for function calls for the current filetype should affect tweaking change.target for the same filetype. The omission of the change key is just syntactic sugar, but they should remain separate I feel.

[latipun7]

Great 🎉
Waiting for this PR appeared in a release tag 👍 (since I install this plugin pinned to latest tag 😃)

[kylechui]

@latipun7 There are (unfortunately) still quite a few bugs that need to be ironed out, as well as user config interface decisions that need to be made. This most likely will not appear in a release for a little bit, unless something magical happens and I'm satisfied with the quality of the code.