[bug?] [mini.ai] next and prev search methods behave asymmetrically

[drowning-cat]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.ai

Question

ai.mp4

local MiniAi = require("mini.ai")

MiniAi.setup({
  custom_textobjects = {
    F = MiniAi.gen_spec.treesitter({ a = "@function.outer", i = "@function.inner" }),
  },
})

vim.keymap.set("n", "gj", function()
  MiniAi.move_cursor("left", "a", "F", { search_method = "next" })
end, {})
vim.keymap.set("n", "gk", function()
  MiniAi.move_cursor("left", "a", "F", { search_method = "prev" })
end, {})

local function outer1()
  local function inner1() end
  local function inner2() end
  inner1()
  inner2()
end

function outer2()
  local function inner1() end
  local function inner2() end
  inner1()
  inner2()
end

local function outer3() end

outer1()
outer2()
outer3()

Press:

15j
6 * gj
gk
gk

I'd like to hear other opinions, but to me it feels unintuitive. Personally, I'd prefer the nvim-treesitter-textobject behavior, where both directions follow the same jump chain. Maybe cover_or_next and cover_or_prev should stay the way they are, while next and prev follow nvim-treesitter-textobject-like approach instead. But my brain has been malfunctioning lately, so I'm not entirely sure.

[echasnovski]

It seems to work as expected and is mostly the matter of choosing the correct distance approach when computing which span is the closest.

It was a long time ago, but I remember trying to find the most intuitive behavior and the current one was the one. The basic idea is to find the region for a textobject match that is "closest in that direction". This means that:

• For "next" it chooses a region with its closest left/start position that is after the cursor. This is true for all six gj cases, even the ones nested in other regions.
• For "prev" it chooses a region with its closest right/end position that is before the cursor. This is true for all gk cases, since every one moves cursor to the matching region's start. If the mapping was for "right" side, it would have traversed all the matches from the gj case, just landing at their ends.

I don't think there is a universally good answer to this, apart from maybe a more comprehensive set of mappings. Like all combinations of [ / { / ] / } that would mean something like "forward to the left side" or "backward to the right side". This feels a bit too much for 'mini.ai', but I have some similar ideas for planned 'mini.hierarchy'.

[drowning-cat]

I'm doing jumping with dot-repeat support via nvim-treesitter-textobjects (part of the code):

  vim.keymap.set({ "n", "x", "o" }, "]]" .. key, function() MiniAi.move_cursor("left", ai_type, id, { search_method = "next" }) end, { desc = desc })
  vim.keymap.set({ "n", "x", "o" }, "[[" .. key, function() MiniAi.move_cursor("left", ai_type, id, { search_method = "prev" }) end, { desc = desc })
  vim.keymap.set({ "n", "x", "o" }, "][" .. key, function() MiniAi.move_cursor("right", ai_type, id,{ search_method =  "next" }) end, { desc = desc })
  vim.keymap.set({ "n", "x", "o" }, "[]" .. key, function() MiniAi.move_cursor("right", ai_type, id,{ search_method =  "prev" }) end, { desc = desc })

For example, if I use ]]a (argument) followed by ; and press it more times than needed, then try to jump back with [[a (,), it can skip over a few entries instead of returning to the expected position.

I've partially mitigated this by using nvim-treesitter-textobjects for jumping treesitter stuff, but that doesn't solve the issue when it comes to patterns. I kinda understand the underlying logic, but it still feels a bit odd for my workflow. I guess I need to press []a followed by g[a.

Anyway, thanks for your answer.