Pre-release v2.0.0

[kylechui]

Hi everybody! This thread will be dedicated to discussing the upcoming v2.0.0 and its new feature set/tweaked user configuration interface. Please feel free to express your thoughts on the update in the comments below: suggestions, bug fixes, and general comments are all welcome! I would really like to stabilize the user configuration interface once and for all, so if there are names that are even slightly confusing/seem out of place, please tag me and let me know.

Here's the list of breaking changes since v1.0.0. They're all relatively minor renames, so hopefully it's not too bad :)

New Features

• Adds first-class Tree-sitter support for finding parent selections; see :h nvim-surround.config.get_selection()
• 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

Here's a small example of how the new Tree-sitter nodes can be used to discern what patterns could not:

treesitter_demo_2.mp4

I'm still not 100% sure on whether or not I want to set up filetype-specific surrounds by default, but the list that I was planning on using can be found here.

[echasnovski]

As far as I can tell, the only purpose of filetype setup is to declare which tree-sitter node defines target object. Is this the case?

If it is indeed, I would recommend using more tree-sitter native approach to solving this problem by relying on queries. Here how this is done in nvim-treesitter/nvim-treesitter-textobjects. Basically, for every filetype there is a file which with help of tree-sitter query magic defines captures which can be used along with other nodes. You can either create your own queries (maybe by cherry-picking ones from nvim-treesitter-textobjects) with "namespaced" captures or tell users how to get/set those queries. This is the way I decided to go in 'mini.ai' and soon will be the case in 'mini.surround'.

With this approach there is no need to create all these autocommands but rather use something like config.get_selection({ node = "@call.outer" }).

[kylechui]

Ok I've finally had some more time to think about how exactly I want to implement things; so far I have two ideas for how queries could be integrated:

1. Use existing queries. The user would have to specify which query they would like to call, as well as the source. E.g. for nvim-treesitter-textobjects, the user would need to specify @call.outer and textobjects
2. Have the user script new queries "on-the-fly". The user would provide the S-expression that represents the query, as well as which capture group from the query they would like to match for. For example, the query string could be

(function_call
  (arguments
    (function_call))) @my_capture

and the capture group would be my_capture. The idea here is that even if you want to match for a large section, you could capture a subset to be the actual retrieved selection. It's analogous to using capture clauses for Lua pattern-matching in my current setup.

While I think case 2 can be done as a subset of case 1 (by simply asking the user to write their queries in a file, instead of directly in the configuration), I think it makes sense to allow them to put all configuration-related scripts in one spot. One of the problems I'm facing now is just what to actually call these things.

Right now I feel like since capture groups are provided for both, it might make sense to have only three keys, where the capture key is "shared" between two use cases. For example:

-- nvim-treesitter-textobjects, case #1
M.get_selection({ query = { capture = "call.outer", type = "textobjects" } })
-- on-the-fly, case #2
M.get_selection({ query = { capture = "my_capture", sexpr = "(function_call) @my_capture" } })

In the above I'm using the keys capture, type, and sexpr to get particular selections. As always, I would appreciate any feedback on the names!

Edit: This would allow for selecting outer function calls, for example via the first query I provided above.

[echasnovski]

While I think case 2 can be done as a subset of case 1 (by simply asking the user to write their queries in a file, instead of directly in the configuration), I think it makes sense to allow them to put all configuration-related scripts in one spot.

I am not sure how you plan this to work. Queries highly depend on language parser and need to be configured as such. There is a built-in mechanism for that (query files in 'queries' directory) which you use in "case 1". Do you want to go back to autocommands and filetypes but now make them optional?

[clason]

There is a built-in mechanism for that (query files in 'queries' directory)

I'm sorry, but no -- that just matches queries to parser names and can't handle different parser versions (which is a frequent pain point). We're still trying to figure out a solution to this problem.

[kylechui]

Ah wait, I just realized that queries are already filetype-specific like they're already in ftplugin 😅 Forget case 2 then; users can just provide their own queries by calling them from their own config files. Thanks for the sanity check haha

Edit: There could be some merit to defining a query for a specific buffer instead of an entire filetype, but to my knowledge the query doesn't really do anything unless it is "referenced"(?) so it should be fine with just case 1 here.

[echasnovski]

I'm sorry, but no -- that just matches queries to parser names and can't handle different parser versions (which is a frequent pain point). We're still trying to figure out a solution to this problem.

Yes, that's true. What I really meant was more in terms of "configure query in FileType autocommand" vs "put query in 'after/queries/<language>/custom.scm'".

[ggandor]

I think _cur and _line as suffixes are really perplexing. "Cursor"? "Current..." what? _cur->current_line and _line->_linewise (or maybe _around_line?) would be much clearer.

[kylechui]

As per :h nvim-surround.config.keymaps:

The `keymaps` table defines the keymaps used to perform surround actions. The
general rule is that if the key ends in "_line", the delimiter pair is added
on new lines. If the key ends in "_cur", the surround is performed around the
current line.

I agree that the names could probably be a bit better; however I would like to have a comprehensive set of names for all normal mode binds (including the current cur_line) before I decide to make any changes.