[mini.operators] some operators have issues with newlines at start/end of textobject

[TheLeoP]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version of the main branch

Module(s)

mini.operators

Neovim version

0.11.x

Description

Using both mini.ai (not required, but allows better control/knowledge of how the textobjects for the operators are selected) and mini.operators default configuration, given the buffer

foo(
  a,
  b,
  c
)

, and with the cursor above a, doing yi) and then gri) results in the buffer

foo
  a,
  b,
  c

)

while I would expect it to result in the same buffer. Similar results can be seen with the multiply operator. gmi) results in

foo(
  a,
  b,
  c(
  a,
  b,
  c
)

note the ( after c that should not be part of the textobject.

This happens because in

mini.nvim/lua/mini/operators.lua

Lines 1167 to 1171 in 9b935c2

	if data.mode == 'visual' and vim.o.selection == 'exclusive' then
	keys = ('`' .. mark_from) .. submode .. ('`' .. mark_to) .. ('"' .. register .. operator)
	else
	keys = ('`' .. mark_from) .. ('"' .. register .. operator .. submode) .. ('`' .. mark_to)
	end

keys ends up being something similar to `["_dv`]. Then, when Neovim moves the cursor to the [ mark, since it isn't on visual mode and virtualedit default value is empty, instead of putting the cursor on the newline after (, the cursor is placed on the parenthesis itself.

This issue can be (partially) solved by temporarily changing virtualedit to onemore inside of

mini.nvim/lua/mini/operators.lua

Line 1149 in 9b935c2

H.do_between_marks = function(operator, data)

(like it is already done on mini.ai for selecting a textobject). After that change, the first example no longer deletes the (, but it still duplicates the newline after c. So the end result is

foo(
  a,
  b,
  c

)

I've been look at it for a while, but I'm not sure as to why. Yanking (yi)) includes the trailing newline after c and mini.ai tries to move the cursor to {4, 4} when selecting the textobject. But, replacing gri)does not include the trailing newline after c when deleting the text. vim.api.nvim_buf_get_mark(0, ']') returns {4, 2} and `] moves the cursor up to c. So, my guess is that this second part of the issue may have something to do with Neovim internals (?

Reproduction

1. Create separate 'nvim-repro' config directory:

   • '~/.config/nvim-repro/' on Unix
   • '~/AppData/Local/nvim-repro/' on Windows

2. Inside 'nvim-repro' directory create a file named 'init.lua'.
   Populate it with the following content:

   -- Clone latest 'mini.nvim' (requires Git CLI installed)
   vim.cmd('echo "Installing `mini.nvim`" | redraw')
   local mini_path = vim.fn.stdpath("data") .. "/site/pack/deps/start/mini.nvim"
   local clone_cmd = { "git", "clone", "--depth=1", "https://github.com/nvim-mini/mini.nvim", mini_path }
   vim.fn.system(clone_cmd)
   vim.cmd('echo "`mini.nvim` is installed" | redraw')
   
   -- Make sure 'mini.nvim' is available
   vim.cmd("packadd mini.nvim")
   require("mini.deps").setup()
   
   -- Add extra setup steps needed to reproduce the behavior
   -- Use `MiniDeps.add('user/repo')` to install another plugin from GitHub
   
   require("mini.ai").setup()
   require("mini.operators").setup()

3. Run NVIM_APPNAME=nvim-repro nvim (i.e. execute nvim with NVIM_APPNAME environment variable set to "nvim-repro").
   Wait for all dependencies to install.

4. Insert the following text in the buffer

foo(
  a,
  b,
  c
)

5. Put the cursor above a, yi) and gri)

The resulting buffer will be

foo
  a,
  b,
  c

)

[echasnovski]

Thanks for the issue!

Yeah, these kind of edge cases are hard to fix; especially in 'mini.operators' since it has to deal with all kinds of Vim motions/selections edge cases. To the point when I am tempted to describe this as a known limitation. But would indeed first require an investigation and an honest attempt to fix this in a reasonably concise way.

This issue can be (partially) solved by temporarily changing virtualedit to onemore inside of

Yeah, that would be my first idea to try if it is not already.

I've been look at it for a while, but I'm not sure as to why.

If you wouldn't find the issue in 'mini.operators' or Neovim (or probably Vim's) behavior, I'll take look (hopefully) tomorrow.

[TheLeoP]

While staring at the problem with the trailing newline I realized that replace is also broken in visual mode when the textobject has newlines at start/end. Even after #2248 . Moving the temporary virtualedit=onemore even higher up the call stack (so it is active for both the deleting and pasting steps) seems to also solve the issue for leading newlines in visual char mode

[TheLeoP]

It also seems like custom textobjects can't know if the last line of the textobject has a trailing newline.

I created the simply operator

---@param type 'line'|'char'|'block'
_G.my_yank = function(type)
  local mode = type == "line" and "V" or type == "char" and "v" or vim.keycode "<c-v>"
  local yanked = vim.fn.getregion(vim.fn.getpos "'[", vim.fn.getpos "']", { type = mode })
  -- __PRINT_VAR_START
  print([==[┆_G.my_yank┆ ╎yanked╎ ┊1┊:]==], vim.inspect(yanked)) -- __PRINT_VAR_END
end
vim.keymap.set({ "x", "n" }, "<F4>", function(a)
  vim.o.operatorfunc = "v:lua._G.my_yank"
  return "g@"
end, { expr = true })

and opened the buffer

foo(
  a,
  b,
  c
)

both <f4>i) and vi)<f4> print the last line as c, no matter if the cursor in visual mode is above the c or one character to the right (so, above the newline).

However, builtin operators like y and d seem to make a distinction between both cases for visual mode (if the cursor if above the c, the newline is not deleted/yanked, if the cursor is one character to the right the newline is deleted/yanked). Doing di) and yi) correctly includes the trailling newline.

I also realized that after vi)<f4> the value of the mark ] was {4,2}, but the value of the mark > was {4,3}. However, changing the textobject to

---@param type 'line'|'char'|'block'
_G.my_yank = function(type)
  if vim.api.nvim_get_mode().mode == "v" then vim.cmd.normal(vim.keycode "<c-\\><c-n>") end

  local mode = type == "line" and "V" or type == "char" and "v" or vim.keycode "<c-v>"
  local yanked = vim.fn.getregion(vim.fn.getpos "'<", vim.fn.getpos "'r", { type = mode })
  -- __PRINT_VAR_START
  print([==[┆_G.my_yank┆ ╎yanked╎ ┊1┊:]==], vim.inspect(yanked)) -- __PRINT_VAR_END
end
vim.keymap.set({ "x", "n" }, "<F4>", function(a)
  vim.o.operatorfunc = "v:lua._G.my_yank"
  return "g@"
end, { expr = true })

and doing vi)<f4> still does not include the trailling newline.

Based on that information, I think that it should be possible to account for the trailing newline if using nvim_ API functions and only for visual char mode. But, I think that it's not possible to do so for both visual mode and textobjects, specially when using normal mode commands directly.

[TheLeoP]

I've opened neovim/neovim#37664 on the Neovim repo. The limitation of custom operators not being able to distinguish between regions with and without a trailing newline (while builtin operators are able to) comes from the C implementation of both. So, it seems like we can't do anything about the trailing newline in the mini.nvim side of things.

I'll slightly modify #2248 to temporarily change onemore upper in the call stack (probably on each MiniOperators.xxx function) to account for the bug on MiniOperators.Replace that's present on MiniOperators.replace only in visual mode mentioned earlier. After that, It should be ready to be merged

[echasnovski]

This should now be fixed on latest main as best as it can reasonably do. More details in this comment.

Thanks again for spotting this and researching about the solution.