mini.ai/surround can't match pair crossing lines when another pair in the same line

[wodesuck]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version

Module(s)

mini.ai/surround

Description

Having

f(g(),
  h())

mini.ai/surround can't match parentheses of f() because the searching algorithm search in the current line first.

Neovim version

0.7.2

Steps to reproduce

1. nvim -nu minimal.lua
2. Create a buffer with text

f(g(),
  h())

3. Set cursor on the first (, type va( or sh(.

Expected behavior

Select the parentheses of f().

Actual behavior

Parentheses of g() are selected.

[echasnovski]

This depends on config.search_method. In 'mini.ai', default is cover_or_next, which does indeed result into g(), because it first searches within line. I personally and users of 'targets.vim' found this behavior more useful. This is by design.

If you set config.search_method = 'cover', it does select parenthesis of g().

[wodesuck]

I also do love cover_or_next, but I expect to select f() when cursor on f or the first (, which targets.vim and builtin does. Only two positions could select f() with mini.ai is , and the last ). I think mini.ai should be an improved builtin, at least some option to make it behave more like builtin.

[echasnovski]

Yeah, you are right that 'targets.vim' selects whole f() when cursor is on f or first (. I thought it isn't. Also judging by its help it should not be the case for cursor on f: it should prefer rr (start and end of target are right of cursor in current line) over rb (from right of cursor in current line to below cursor on screen).

At the moment I am almost certain that this behavior won't change in the near future. Mainly for two reasons:

• I can't formulate a coherent and concise way of why it should prefer f() over g() while still preferring latter on the rest of the line in case of cover_or_next.
• It seems to might need a lot of code change for a (what I perceive at the moment as) minor feature change.

[wodesuck]

According to the help of targets.vim:

When using a command like cib to change inside a block, targets.vim considers the three targets:

   smallest target around cursor
   next target after cursor
   last target before cursor

For each of those that were found, we detect what range type it has. A range type depends on the relative position of the start and end of the target, relative to the current cursor position and the currently visible lines.

I guess that is how targets.vim select f() when cursor on f:

First, find three targets:

• Cover? Not found.
• Next? Found, f().
• Before? Not found.

So f() is the only one choice, and there is no need to consider g:targets_seekRanges anymore. g() is not being considered from the very first step because it is not a "next textobject", only f() is.

It may not so many code change as you thought, we could search the cover and next textobject in the n_lines region directly (instead of searching current line first), and then consider which one should be choice depend on they are in the current line or not.

[echasnovski]

I guess that is how targets.vim select f() when cursor on f:

Yep, seems like it.

... and then consider which one should be choice depend on they are in the current line or not.

This part is tricky because best match is searched in "1d neighborhood" (before and after lines concatenated with \n), where knowledge about "is in current line or not" is not as straightforward.

Anyway, I'll keep this suggestion in mind and see if something can be done here.