[mini.ai] New search_method 'cover_or_next_or_prev'

[Lolligerhans]

The default search method is cover_or_next. vib selects the surrounding block, or the next block if there is no surrounding block.

A reasonable fallback when forward search fails is a backward search. Uncontroversial special cases may be

• the cursor being at the end of the file or
• the file containing only 1 of the desired text-object

and I speculate this additional fallback would be preferred by some users in the general case.

The cover_or_next method presumably exists for similar reasoning: If the user knows the preferred method will fail, they can cover move cases with fewer commands by deliberately entering a fallback. Stock Nvim has a similar effect for the " objects where the next quote is chosen implicitly.

Some users may prefer the current behavior because it allows deducing the existence of the searched text object in the specified direction. This is especially plausible when:

• the forward direction is specified explicitly (vinb rather than vib), or
• the user intends to learn about the existence of the chosen text object in some direction (in which case using n or l explicitly should remain as is).

---

Proposed behavior:

• Use 'cover_or_next_or_prev' search method when n/l not specified (method does not exist yet)
• When n/l invoked, do not fallback to the other direction

[echasnovski]

Thanks for the suggestion!

The main reason cover_or_next was chosen as a default search method in 'mini.ai' is indeed because this is how most of charwise Neovim's textobjets work (at least partially, only within a current line). However, this was the choice before explicit an / in / al / il search modifiers existed (they were added very soon after initial release thanks to the community feedback).

At the moment I do regret having cover_or_next as a default, because it is not simple and not intuitive at times (due to performance considerations). I would have liked to have just cover as a default method (as in 'mini.surround') in favor of suggesting to use explicit variants to search forward or backward.

So I am afraid introducing even more complex search method goes against this whole line of reasoning. Still, thank you for taking time to write this!