mini.ai vs. treesitter-textobjects for treesitter keymaps

[smjonas]

First of all, thanks for your contributions to the Neovim community and your high-quality plugins!

I was wondering whether there would be any benefit of me changing my current setup for nvim-treesitter-textobjects with a config for mini.ai. I.e. I have:

require("nvim-treesitter.configs").setup {
    textobjects = {
      select = {
        enable = true,
        -- Automatically jump forward to textobj, similar to targets.vim
        lookahead = true,
        keymaps = {
          ["af"] = "@function.outer",
          ["if"] = "@function.inner",
          ["ac"] = "@class.outer",
          ["ic"] = "@class.inner",
          ["ia"] = "@parameter.inner",
          ["ai"] = "@conditional.outer",
          ["ii"] = "@conditional.inner",
        },
      },
   }
}

What's the difference between using this approach vs. mini.ai combined with

  require('mini.ai').setup({
    custom_textobjects = {
      ...

?

Are there any performance differences perhaps?

[echasnovski]

Probably no performance difference, but I didn't make a thorough check.

Most differences come from slightly different features:

• You can configure search method to be more nuanced, not only similar to lookahead = true. See this help section about search methods.
• Following previous note, there are "next"/"last" variants of textobjects (an/in/al/il). Basically, they select textobject with temporarily changed search method (next and prev respectively). Initially they were not part of 'mini.ai', but I've gotten several people describing their benefits and boy was I wrong. They are really useful especially with combination with dot-repeat. Like you can use cin' to edit inside next quotes while being inside quotes (which is less movement) and it will be dot-repeatable.
• Consecutive application. This is like incremental selection in 'nvim-treesitter', but for this particular text object. So being inside two nested {} you can va}a} or v2a} (yes, it supports [count] as well) and it will select outer {}.

There are also slight non-obvious caveats in 'mini.ai' design:

• Also, one important difference (probably) is how it searches in case of default cover_or_next method. It first searches inside reference region lines (currently selected lines; usually just current line) and only after that tries to search neighborhood. This is be design and likely won't change. See mini.ai/surround can't match pair crossing lines when another pair in the same line #116 for example. If you don't like it, I'd suggest use search_method = 'cover' and be more explicit with an/in if you want next textobject.
• For performance reasons it searches only inside config.n_lines neighborhood of reference region lines. To mitigate that, set it to a very high number.

[echasnovski]

This setup seems to be equivalent to yours:

local ai = require('mini.ai')
local spec_treesitter = ai.gen_spec.treesitter
ai.setup({
  custom_textobjects = {
    -- This will override default "function call" textobject
    f = spec_treesitter({ a = '@function.outer', i = '@function.inner' }),
    c = spec_treesitter({ a = '@class.outer', i = '@class.inner' }),
    -- This will possibly conflict with textobjects from 'mini.indentscope':
    -- If typed quickly (within 'timeoutlen' milliseconds),
    -- 'mini.indentscope' will be used, this one otherwise.
    i = spec_treesitter({ a = '@conditional.outer', i = '@conditional.inner' }),
  }
})

[smjonas]

Thank you for the explanation! I didn't think about the next prev / last textobjects and the support for count in the context of treesitter textobjects but those definitely seem like features worth switching to pure a mini.ai setup for! Also thanks letting me know about the consecutive application feature, I didn't know that, and for providing me with the code :)